Andreas Raab writes:
Messages usually have the arguments last. Wouldn't it be nice to have messages that could have arguments between a phrase?
No.
[...]
aBitStream next: 40 bits
[...]
The above should be written as
aBitStream next: 40 "bits"
I thought the trailing no-op in the message selector was a nice idea.
Comments aren't as good as the message selector syntax. Comments get out of date and people leave them out. If it's really worth mentioning in a comment, that you're expecting with 40 _bits_, then it's worth making this explict/mandatory using the method selector.
Also, the trailing no-op in the method-selector allows you to have a similar method you invoke like this:
aBitStream next: 40 bytes.
It looks like the main difficulty would be that the resulting language couldn't be parsed without extra information - you'd need to know whether or not there was a message called #next:bits to decide whether or not "aBitStream next: 40 bits" meant ((aBitStream next: 40) bits).
-- Matthew McDonald mafm@cs.uwa.edu.au
Hi,
aBitStream next: 40 bits
I thought the trailing no-op in the message selector was a nice idea.
[...]
Also, the trailing no-op in the method-selector allows you to have a similar method you invoke like this:
aBitStream next: 40 bytes.
In this case, it's NOT a nop - it's part of the method's selector and that is an entirely different issue. I agree that for readability it may be nice to have a selector like "next:bits" instead of "nextBits:" but if you really treat the "bits" as no information I don't see any added value - it only makes parsing AND understanding the code harder (because you have to know if "bits" is a selector or just a comment).
Andreas
At 01:37 PM 11/2/98 +0800, Matthew McDonald mafm@cs.uwa.edu.au wrote:
It looks like the main difficulty would be that the resulting language couldn't be parsed without extra information - you'd need to know whether or not there was a message called #next:bits to decide whether or not "aBitStream next: 40 bits" meant ((aBitStream next: 40) bits).
[Incidentally, that would be (aBitStream next: (40 bits))]
Knowing what method selectors exist in the image would not be enough. If there existed #next:bits, #next:, and #bits, you would not be able to tell which interpretation of "<expr1> next: <expr2> bits" was the proper one without knowing (and you can't) the types of the expression results. What's even worse, in a dynamic environment where selectors come and go, adding or removing a selector would mean potentially changing the parse tree of some of the already compiled methods.
--Vassili
or not "aBitStream next: 40 bits" meant ((aBitStream next: 40) bits).
First, it already says aBitStream, so the second pseudo-selector-noop-bits is just stuttering reminicent of programming in java. I.E.
BitStream bitStream = BitStream.newBits(...)
Either it is unambiguous that you mean bits, in which case the second bits pseudo-selector-part is unneeded, or there is a posible second semantics, let's say it could be bytes of any size, 1 to n.
The I would do: (for a machine with a ten-bit byte size)
aBitstream next: numberOfNotNecesarily8BitBytes byteSize: 10
and expect to get back a sequence of Integers between 0 and 1023.
-- Mike
P.S. Somebody on the list uses Knuths quote about it being intollerable to depend on a specific byte size. I actually like the term Octet. What say we rename ByteArray to OctetArray :-) Nah. 8-bit Bytes are just too entrenched. Be carefull when you make you bed. You may be sleeping in it a looooong time.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Matthew McDonald -
Michael S. Klein -
Vassili Bykov