the := operator (affectation

[Dennis Brown]

> okay.. back into my hole...

Yes, Please stay there.

> I personally have nothing against ":=" and "=" for variable  
> assignment and have used them
> My problem with the concept of "gets" is that I can't see how it  
> fits within the conceptual framework of xTalk

var := x
var == x
var = x  --this is a bit tougher
var isAssignedToTheValueOf x
var gets x

are all the same thing!

You say one is a good construct and another is an inconsistent  
construct!  That makes your argument inconsistent.

You just don't get it ;-)
I can't say I can get it into your head, though I can put it into  
your head.
Perhaps Jim gets it now.

Ok, this has just turned the corner to religion and I'm outa here...

Dennis

On Jun 23, 2005, at 6:13 PM, Jim MacConnell wrote:

> Hi.
>
> I've been "listening" to this discussion and find it intriguing. I  
> personally have nothing against ":=" and "=" for variable  
> assignment and have used them when using a tool that requires them.  
> I also can quickly adapt to the "==" concept for comparisons and "= 
> +" for incrementing  (Though that one still hurts my brain a  
> little). So... while the discussions about operators has been  
> interesting, it is not something that stirred any passion.... Until  
> the "gets" discussion that is.... and then I realized that I do  
> care....
>
> My problem with the concept of "gets" is that I can't see how it  
> fits within the conceptual framework of xTalk where we (the coders)  
> are telling an object (a button, a field, etc.) what to do when a  
> certain message is received (on blah). The "put" and "get"  
> constructs fall neatly into that vision as does (not surprisingly)  
> most/all other elements (send, do,etc.). In a polite form of the  
> "verbose", we are saying "Please, Button, when you receive a  
> 'mouseUp' message do this and this and this also".  Often, we will  
> throw in a customHandler "xxx" which the object figures is a  
> message if we don't tell it otherwise and so we don't have to say  
> "Send xxx to the target" all the time.
>
> In contrast what is going on with the "gets" construct? Here some  
> renegade variable is off filling itself with data and the button  
> can only assume that it is being done... a weird sort of coding  
> delegation which makes sense in a some environments but not xTalk.  
> It is more like  "Please, Button, when you receive a 'mouseUp'  
> message do this and this and Ooops.. this isn't meant for you so  
> don't pay any attention (Variable... go stuff yourself with  
> something).. and now where were we.. Oh yes.. and this and  
> this...and I hope the variable did its thing because I know you  
> didn't do it Button but I hope the data is there cuz now I need you  
> to do this.... and this   and this also".  I mean "Where's the  
> message?".
>
> I don't mean to be totally facetious but the concept of message  
> path and message passing within the confines of a relatively  
> limited set of "near physical" objects  is in what I view as the  
> core concept of xTalk. The "affectation" discussion is really about  
> alternatives for those who have learned to program in non-message  
> based environments. (Or so my thoughts at this instant  
> indicate)..... and this extends to those thinking ":=", etc. would  
> be a good addition to Transcript.  In contrast I think adding the  
> "put x into y" construct would help a lot of other code (C, VB, + 
> +)  be more readable....
>
> Getting back to "gets"... is it really that much harder to type  
> "put (the x of y) into z" versus "z gets the x of y".
>
> okay.. back into my hole...
>
> Jim
>
>
> James H. MacConnell
>
> Consensus Technology, LLC
> 2200 N. 77th St.
> seattle, WA  98103-4928
> www.consensustech.com
> Tel: 206.524.8555
> Fax: 206.524.3034
>
>
>
> On Jun 23, 2005, at 12:57 PM, Dennis Brown wrote:
>
>
>>  I would be happy to be able to change "get x" to "myVariable  
>> gets  x".
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>