Path: news.cs.au.dk!news.net.uni-c.dk!logbridge.uoregon.edu!skynet.be!poster!not-for-mail From: Atle Newsgroups: comp.lang.beta Subject: Re: Tha Master of Stupid Questions is back =?iso-8859-1?Q?=C6=C6=C6=C6H=21?= Date: Thu, 15 Jun 2000 19:09:56 -0100 Organization: Belgacom Skynet SA/NV Lines: 32 Message-ID: <39493814.250162AB@skynet.be> References: <393FA45B.FD97119D@skynet.be> NNTP-Posting-Host: dialup49.charleroi.skynet.be Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news1.skynet.be 961088772 17455 195.238.7.49 (15 Jun 2000 17:06:12 GMT) X-Complaints-To: abuse@skynet.be NNTP-Posting-Date: 15 Jun 2000 17:06:12 GMT X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en Xref: news.cs.au.dk comp.lang.beta:12407 Flemming Gram Christensen wrote: > > > given that MyP is a reference to a p object we can use the attributes like: > a) MyP.s or > b) MyP.s[] or > c) MyP.t or > d) MyP.t[] which means: > > a: execute MyP.q's dopart. I will have some questions regarding 'execute' vs. 'allocate' - but I am approaching the end of my 'first reading' of the BetaBook, so I will wait. But I will be seeking some clarification, since I have 'grown up' with a strict separation of active objects = functions, code and passive objects = variables, data. I need to find a new way to look at this, and I will be asking for more 'theoretical' references who treat the underlying philosophy more than specific examples. But, BetaBook first :-) > > One could write example a as MyP.s@ and b as MyP.s^ ? > I would not like it. I needed to know this. Since I am used to seeing fx. * both in declarations and access, I didn't want an ugly surprise like MyP.s -> someVar^ or ^someVar, @someVar, etc. cf. use of ^ in Pascal, and in particular, & in C++. As long as I know it, I absolutely agree with the idea of keeping one symbol for declaration and another for use. It is 'neater'. > > I do not know. Some of the syntax was chosen deliberately to not look > like C. Not a bad choice, either. We need all the help we can get to throw 'bad knowledge' overboard and make room for 'good knowledge'. It would be bad if something had a similar syntax with totally different semantics. > Thanks once more, Atle