Case-sensitive behavior of clone?

Thread: Case-sensitive behavior of clone?

Search this list only Search all lists
Case-sensitive behavior of clone?
	2006-05-23 04:53:31
On May 23, 2006, at 12:33 AM, Jeremy Tregunna wrote: > An identifier beginning with a capital character and immediately  > following it is an assignment operator (:=) is transformed into the  > message "setSlotWithType" which acts just like setSlot but also  > sets the type slot on the object before returning it. It is more a  > way of avoiding having to write out an explicit type slot. This is  > infact, the most common way identifiers are named. Capitalized  > camel case names are for protos, lower case identifiers for others. This should really, really be documented. Is it and I'm just missing  it? I was unaware of any case-dependent behaviour. - John
Case-sensitive behavior of clone?
	2006-05-23 05:05:38
> > On May 23, 2006, at 12:33 AM, Jeremy Tregunna wrote: > > > An identifier beginning with a capital character and immediately > > following it is an assignment operator (:=) is transformed into the > > message "setSlotWithType" which acts just like setSlot but also > > sets the type slot on the object before returning it. It is more a > > way of avoiding having to write out an explicit type slot. This is > > infact, the most common way identifiers are named. Capitalized > > camel case names are for protos, lower case identifiers for others. > > This should really, really be documented. Is it and I'm just missing > it? I was unaware of any case-dependent behaviour. It was "experimentally" added to the dev repo (not that we have any other one ). Quag partially implemented the IoProp and that is probably the best place to look right now. Note that it is only partial (last time I looked it was missing a few small things). The documentation should be forthcoming once the feature stabilizes (just reminding you that the language is moving fast enough that the docs will always be out of sync until we slow down). Brian.
Case-sensitive behavior of clone?
	2006-05-23 06:16:58
> I was unaware of any case-dependent behaviour. I don't like case-dependent behaviour. :--(   Let's just make the  type setting the default behaviour for ALL slots.  As we know, it can  easily be overwritten. Jason the simplicity fanatic
Case-sensitive behavior of clone?
	2006-05-23 06:35:55
> I don't like case-dependent behaviour. :--(   Let's just make the > type setting the default behaviour for ALL slots.  As we know, it can > easily be overwritten. +1
Case-sensitive behavior of clone?
	2006-05-23 07:08:59
> On May 23, 2006, at 1:16 AM, Jason Grossman wrote: > > > I don't like case-dependent behaviour. :--(   Let's just make the > > type setting the default behaviour for ALL slots.  As we know, it can > > easily be overwritten. > > +1 Ok. I think it is time I chime in again and beg people to consider the scenarios that the type slot is used (again IoProp 3 should cover the bases). It makes no sense to do this for all objects assigned to a slot at all as it breaks a lot of the useful cases for the slot. I will let you do the homework otherwise I am not sure if your opinion matters. Secondly, it needs to be noted that this is part of idiomatic code. It is along the same line of conventions already used for naming things. If you find this code inconsistent with the semantics in your code then you are most likely writing non-idiomatic code. Code which, frankly, is almost harder to write than following simple (yes simple) rules. Upper case slots usually hold meaningful and qualified prototypes that are ripe candidates for cloning. There are very few cases where it is appropriate for something to remain anonymous that will be cloned later on. In fact it only hurts when that practice is taken because things like exception output reverts to very primitive and unhelpful messages like 'Object does not respond to ...'. Last but not least, an note about where simplicity can matter. Simplicity is not only important in the language specification (I think Io meets this area quite well) but in the automation and work needed to utilized the language in a productive and correct manner (automation helps here). This is an automation to make the general case a friendly one. Now we don't have to receptively set a type slot to get useful information back from Io when we need it (think of this as inspiration from the DRY principle). Io needs this automation or else we might as well call SK-calculus simple and drop work where we are . Io already automates a lot and will probably be doing more as we find cases where it is a improvement over what was there before in respect to the programmers experience using the language. Anyway, please focus on enjoying the language rather than picking it apart like a mathematical proof. As long as we can program what we need easily and elegantly then we can all, hopefully, live another happy day doing what we enjoy. Brian.