|
« Return to Thread: Strange behaviour when using CAPS for a slot name
Re: Re: Strange behaviour when using CAPS for a slot name
by Rich Collins
::
Rate this Message:
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@
> > > >
> > >
> > >
> > >
> >
>
>
>
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@
> > > >
> > >
> > >
> > >
> >
>
>
>
« Return to Thread: Strange behaviour when using CAPS for a slot name
| Free embeddable forum powered by Nabble | Forum Help |
