Strange behaviour when using CAPS for a slot name

[joh_90uk]

Steve, I see rather strange behaviour when using caps for a variable name. See below:

Io> 55 type
==> Number
Io> aa:=55
==> 55
Io> 55 type
==> Number
Io> AA:=55
==> 55
Io> 55 type
==> AA

So by using a caps slot name during a slot assignment, the type of the subject of that assignment is changed to the name of the slot. Not sure why this is happening but I'm guessing it was not intended.

[Jeremy Tregunna-2]

On 17-Jun-09, at 8:29 AM, joh_90uk wrote:

> Steve, I see rather strange behaviour when using caps for a variable  
> name. See below:
>
> Io> 55 type
> ==> Number
> Io> aa:=55
> ==> 55
> Io> 55 type
> ==> Number
> Io> AA:=55
> ==> 55
> Io> 55 type
> ==> AA
>
> So by using a caps slot name during a slot assignment, the type of  
> the subject of that assignment is changed to the name of the slot.  
> Not sure why this is happening but I'm guessing it was not intended.

You will see why if you run the following two code snippets:

message(aa := 55) asString

and

message(AA := 55) asString

This was a special case created a couple of years ago to avoid manual  
setting of the type slot. But this is desired behaviour I suppose.

Regards,

Jeremy Tregunna
jeremy.tregunna@...

[joh_90uk]

The capitalisation of a variable name changes the behaviour of an operator - that's not pretty! It's also not documented in the guide:

::= Creates slot, creates setter, assigns value
:= Creates slot, assigns value
= Assigns value to slot if it exists, otherwise raises exception

These operators are compiled to normal messages whose methods can be overridden. For example:

source compiles to
a ::= 1 newSlot("a", 1)
a := 1 setSlot("a", 1)
a = 1 updateSlot("a", 1)

Luckilly ::= doesn't seem to have the same issue so I'll use that instead (don't really want a getter/setter as it is a constant but it'll do). Cheers,

ChrisM

--- In iolanguage@..., Jeremy Tregunna <jeremy.tregunna@...> wrote:

>
>
> On 17-Jun-09, at 8:29 AM, joh_90uk wrote:
>
> > Steve, I see rather strange behaviour when using caps for a variable  
> > name. See below:
> >
> > Io> 55 type
> > ==> Number
> > Io> aa:=55
> > ==> 55
> > Io> 55 type
> > ==> Number
> > Io> AA:=55
> > ==> 55
> > Io> 55 type
> > ==> AA
> >
> > So by using a caps slot name during a slot assignment, the type of  
> > the subject of that assignment is changed to the name of the slot.  
> > Not sure why this is happening but I'm guessing it was not intended.
>
> You will see why if you run the following two code snippets:
>
> message(aa := 55) asString
>
> and
>
> message(AA := 55) asString
>
> This was a special case created a couple of years ago to avoid manual  
> setting of the type slot. But this is desired behaviour I suppose.
>
> Regards,
>
> Jeremy Tregunna
> jeremy.tregunna@...
>

[Rich Collins]

It avoids having to do this:

SomeProto := Object clone setType("SomeProto") do( ...

On Jun 17, 2009, at 6:17 AM, joh_90uk wrote:

>
>
> The capitalisation of a variable name changes the behaviour of an  
> operator - that's not pretty! It's also not documented in the guide:
>
> ::= Creates slot, creates setter, assigns value
> := Creates slot, assigns value
> = Assigns value to slot if it exists, otherwise raises exception
>
> These operators are compiled to normal messages whose methods can be  
> overridden. For example:
>
> source compiles to
> a ::= 1 newSlot("a", 1)
> a := 1 setSlot("a", 1)
> a = 1 updateSlot("a", 1)
>
> Luckilly ::= doesn't seem to have the same issue so I'll use that  
> instead (don't really want a getter/setter as it is a constant but  
> it'll do). Cheers,
>
> ChrisM
>
> --- In iolanguage@..., Jeremy Tregunna  
> <jeremy.tregunna@...> wrote:
> >
> >
> > On 17-Jun-09, at 8:29 AM, joh_90uk wrote:
> >
> > > Steve, I see rather strange behaviour when using caps for a  
> variable
> > > name. See below:
> > >
> > > Io> 55 type
> > > ==> Number
> > > Io> aa:=55
> > > ==> 55
> > > Io> 55 type
> > > ==> Number
> > > Io> AA:=55
> > > ==> 55
> > > Io> 55 type
> > > ==> AA
> > >
> > > So by using a caps slot name during a slot assignment, the type of
> > > the subject of that assignment is changed to the name of the slot.
> > > Not sure why this is happening but I'm guessing it was not  
> intended.
> >
> > You will see why if you run the following two code snippets:
> >
> > message(aa := 55) asString
> >
> > and
> >
> > message(AA := 55) asString
> >
> > This was a special case created a couple of years ago to avoid  
> manual
> > setting of the type slot. But this is desired behaviour I suppose.
> >
> > Regards,
> >
> > Jeremy Tregunna
> > jeremy.tregunna@...
> >
>
>
>

[joh_90uk]

Would it not be better to do a look ahead for a clone if needs be, rather than depend on capitalisation? Or alternatively have clone() take a parameter with a slot name, giving.

Object clone("SomeProto")

instead of:

SomeProto := Object clone

It seems less "magic" and therefore less prone to confusion.


ChrisM
--- In iolanguage@..., Rich Collins <richcollins@...> wrote:

>
> It avoids having to do this:
>
> SomeProto := Object clone setType("SomeProto") do( ...
>
> On Jun 17, 2009, at 6:17 AM, joh_90uk wrote:
>
> >
> >
> > The capitalisation of a variable name changes the behaviour of an  
> > operator - that's not pretty! It's also not documented in the guide:
> >
> > ::= Creates slot, creates setter, assigns value
> > := Creates slot, assigns value
> > = Assigns value to slot if it exists, otherwise raises exception
> >
> > These operators are compiled to normal messages whose methods can be  
> > overridden. For example:
> >
> > source compiles to
> > a ::= 1 newSlot("a", 1)
> > a := 1 setSlot("a", 1)
> > a = 1 updateSlot("a", 1)
> >
> > Luckilly ::= doesn't seem to have the same issue so I'll use that  
> > instead (don't really want a getter/setter as it is a constant but  
> > it'll do). Cheers,
> >
> > ChrisM
> >
> > --- In iolanguage@..., Jeremy Tregunna  
> > <jeremy.tregunna@> wrote:
> > >
> > >
> > > On 17-Jun-09, at 8:29 AM, joh_90uk wrote:
> > >
> > > > Steve, I see rather strange behaviour when using caps for a  
> > variable
> > > > name. See below:
> > > >
> > > > Io> 55 type
> > > > ==> Number
> > > > Io> aa:=55
> > > > ==> 55
> > > > Io> 55 type
> > > > ==> Number
> > > > Io> AA:=55
> > > > ==> 55
> > > > Io> 55 type
> > > > ==> AA
> > > >
> > > > So by using a caps slot name during a slot assignment, the type of
> > > > the subject of that assignment is changed to the name of the slot.
> > > > Not sure why this is happening but I'm guessing it was not  
> > intended.
> > >
> > > You will see why if you run the following two code snippets:
> > >
> > > message(aa := 55) asString
> > >
> > > and
> > >
> > > message(AA := 55) asString
> > >
> > > This was a special case created a couple of years ago to avoid  
> > manual
> > > setting of the type slot. But this is desired behaviour I suppose.
> > >
> > > Regards,
> > >
> > > Jeremy Tregunna
> > > jeremy.tregunna@
> > >
> >
> >
> >
>

[Rich Collins]

Object clone("SomeProto") having the local side effect of setting a  
slot would be quite unexpected.

I think the problem here is the convention of using capitalized camel  
case for both protos and constants.  I personally don't believe in the  
idea of constants.  I treat constants like normal message sends (as  
does Io: Number constants pi)

On Jun 17, 2009, at 9:56 AM, joh_90uk wrote:

>
>
> Would it not be better to do a look ahead for a clone if needs be,  
> rather than depend on capitalisation? Or alternatively have clone()  
> take a parameter with a slot name, giving.
>
> Object clone("SomeProto")
>
> instead of:
>
> SomeProto := Object clone
>
> It seems less "magic" and therefore less prone to confusion.
>
> ChrisM
> --- In iolanguage@..., Rich Collins <richcollins@...>  
> wrote:
> >
> > It avoids having to do this:
> >
> > SomeProto := Object clone setType("SomeProto") do( ...
> >
> > On Jun 17, 2009, at 6:17 AM, joh_90uk wrote:
> >
> > >
> > >
> > > The capitalisation of a variable name changes the behaviour of an
> > > operator - that's not pretty! It's also not documented in the  
> guide:
> > >
> > > ::= Creates slot, creates setter, assigns value
> > > := Creates slot, assigns value
> > > = Assigns value to slot if it exists, otherwise raises exception
> > >
> > > These operators are compiled to normal messages whose methods  
> can be
> > > overridden. For example:
> > >
> > > source compiles to
> > > a ::= 1 newSlot("a", 1)
> > > a := 1 setSlot("a", 1)
> > > a = 1 updateSlot("a", 1)
> > >
> > > Luckilly ::= doesn't seem to have the same issue so I'll use that
> > > instead (don't really want a getter/setter as it is a constant but
> > > it'll do). Cheers,
> > >
> > > ChrisM
> > >
> > > --- In iolanguage@..., Jeremy Tregunna
> > > <jeremy.tregunna@> wrote:
> > > >
> > > >
> > > > On 17-Jun-09, at 8:29 AM, joh_90uk wrote:
> > > >
> > > > > Steve, I see rather strange behaviour when using caps for a
> > > variable
> > > > > name. See below:
> > > > >
> > > > > Io> 55 type
> > > > > ==> Number
> > > > > Io> aa:=55
> > > > > ==> 55
> > > > > Io> 55 type
> > > > > ==> Number
> > > > > Io> AA:=55
> > > > > ==> 55
> > > > > Io> 55 type
> > > > > ==> AA
> > > > >
> > > > > So by using a caps slot name during a slot assignment, the  
> type of
> > > > > the subject of that assignment is changed to the name of the  
> slot.
> > > > > Not sure why this is happening but I'm guessing it was not
> > > intended.
> > > >
> > > > You will see why if you run the following two code snippets:
> > > >
> > > > message(aa := 55) asString
> > > >
> > > > and
> > > >
> > > > message(AA := 55) asString
> > > >
> > > > This was a special case created a couple of years ago to avoid
> > > manual
> > > > setting of the type slot. But this is desired behaviour I  
> suppose.
> > > >
> > > > Regards,
> > > >
> > > > Jeremy Tregunna
> > > > jeremy.tregunna@
> > > >
> > >
> > >
> > >
> >
>
>
>

[joh_90uk]

I agree and don't :) I agree that using CamelCase of constants isn't the IO convention, I am doing this as I am trying to replicate some legacy C code and want to follow the legacy conventions as close as possible (to show I am doing like for like when comparing the two sets of code). This is of course not ideal and I would not do this if I were writing from scratch.
However I do also think it very strange to have the action of an assignment vary dependant upon the name of the object being assigned to.
I don't agree that clone(someslot) affecting that slot is odd though any more than setSlot(someslot) affecting the slot is odd. I would suggest having the ability to do clone() which doesn't affect the slot and clone(someslot) which does affect the slot is fine - as long as it is documented.
And there in lies the real problem I think, that this unexpected behaviour is not documented, and indeed that the documentation clearly states that := will call setSlot, so to have it calling setSlotWithType() is distinctly unexpected :)

ChrisM

--- In iolanguage@..., Rich Collins <richcollins@...> wrote:

>
> Object clone("SomeProto") having the local side effect of setting a  
> slot would be quite unexpected.
>
> I think the problem here is the convention of using capitalized camel  
> case for both protos and constants.  I personally don't believe in the  
> idea of constants.  I treat constants like normal message sends (as  
> does Io: Number constants pi)
>
> On Jun 17, 2009, at 9:56 AM, joh_90uk wrote:
>
> >
> >
> > Would it not be better to do a look ahead for a clone if needs be,  
> > rather than depend on capitalisation? Or alternatively have clone()  
> > take a parameter with a slot name, giving.
> >
> > Object clone("SomeProto")
> >
> > instead of:
> >
> > SomeProto := Object clone
> >
> > It seems less "magic" and therefore less prone to confusion.
> >
> > ChrisM
> > --- In iolanguage@..., Rich Collins <richcollins@>  
> > wrote:
> > >
> > > It avoids having to do this:
> > >
> > > SomeProto := Object clone setType("SomeProto") do( ...
> > >
> > > On Jun 17, 2009, at 6:17 AM, joh_90uk wrote:
> > >
> > > >
> > > >
> > > > The capitalisation of a variable name changes the behaviour of an
> > > > operator - that's not pretty! It's also not documented in the  
> > guide:
> > > >
> > > > ::= Creates slot, creates setter, assigns value
> > > > := Creates slot, assigns value
> > > > = Assigns value to slot if it exists, otherwise raises exception
> > > >
> > > > These operators are compiled to normal messages whose methods  
> > can be
> > > > overridden. For example:
> > > >
> > > > source compiles to
> > > > a ::= 1 newSlot("a", 1)
> > > > a := 1 setSlot("a", 1)
> > > > a = 1 updateSlot("a", 1)
> > > >
> > > > Luckilly ::= doesn't seem to have the same issue so I'll use that
> > > > instead (don't really want a getter/setter as it is a constant but
> > > > it'll do). Cheers,
> > > >
> > > > ChrisM
> > > >
> > > > --- In iolanguage@..., Jeremy Tregunna
> > > > <jeremy.tregunna@> wrote:
> > > > >
> > > > >
> > > > > On 17-Jun-09, at 8:29 AM, joh_90uk wrote:
> > > > >
> > > > > > Steve, I see rather strange behaviour when using caps for a
> > > > variable
> > > > > > name. See below:
> > > > > >
> > > > > > Io> 55 type
> > > > > > ==> Number
> > > > > > Io> aa:=55
> > > > > > ==> 55
> > > > > > Io> 55 type
> > > > > > ==> Number
> > > > > > Io> AA:=55
> > > > > > ==> 55
> > > > > > Io> 55 type
> > > > > > ==> AA
> > > > > >
> > > > > > So by using a caps slot name during a slot assignment, the  
> > type of
> > > > > > the subject of that assignment is changed to the name of the  
> > slot.
> > > > > > Not sure why this is happening but I'm guessing it was not
> > > > intended.
> > > > >
> > > > > You will see why if you run the following two code snippets:
> > > > >
> > > > > message(aa := 55) asString
> > > > >
> > > > > and
> > > > >
> > > > > message(AA := 55) asString
> > > > >
> > > > > This was a special case created a couple of years ago to avoid
> > > > manual
> > > > > setting of the type slot. But this is desired behaviour I  
> > suppose.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jeremy Tregunna
> > > > > jeremy.tregunna@
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

[klr_home]

--- In iolanguage@..., Jeremy Tregunna
> > So by using a caps slot name during a slot assignment, the type of  
> > the subject of that assignment is changed to the name of the slot.  

> This was a special case created a couple of years ago to avoid manual  
> setting of the type slot. But this is desired behaviour I suppose.

IMO, it would've made more sense if it used a special message on the RHS instead of a capitalized slot name on the LHS. E.g.
  Sunglasses := Glasses newSubtype

This may allow the special behavior (check whether it should assign the type name) to be in newSubtype() instead of in every := assignment. (This would require that a message node used as an argument has a "parent" reference out to the message node which contains it, but that's a very useful practice in my experience.)