The Inbox: Kernel-cmm.464.mcz

A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-cmm.464.mcz

==================== Summary ====================

Name: Kernel-cmm.464
Author: cmm
Time: 19 June 2010, 2:55:08.254 pm
UUID: 2f0eca0f-96b3-4435-b9f0-a7574c11c0b9
Ancestors: Kernel-cmm.463

- Added Object>>#asArray.  This streamlines the use of public API's that permit a collection argument, by not requiring the user of the API to create a collection when only a single element is wanted anyway.

=============== Diff against Kernel-cmm.463 ===============

Item was added:
+ ----- Method: Object>>asArray (in category 'converting') -----
+ asArray
+
+ ^ Array with: self
+
+ !

On 19.06.2010, at 19:55, [hidden email] wrote:

Uh oh. Why not write {object} at the sending site?

- Bert -

When the "sending site" is an actual end-user, API unification eases
their use of the system.  For example, we have a single user-input
that is interpreted on the fly and constructed into a full query
decision tree, this simplifies and unifies the syntax.

Similarly, when dragging an object argument to a Maui Parameter-Holder
doesn't require the user to make a collection.

Any time 1..n objects may be an argument, #asArray _unifies_ the API
to accept, equally, a collection or single-object.

Regards,
  Chris



On Sat, Jun 19, 2010 at 3:00 PM, Bert Freudenberg <[hidden email]> wrote:

maybe #inArray or #asSingleton would be more appropriate: it is not a
conversion, it is an encapsulation.

Stef

Am 19.06.10 22:00 schrieb Bert Freudenberg:
+1.

I don't like this. It has a completely different semantics than the existing
#asArray methods for Collections which is "Answer an Array with all of my
elements". The new method is "Answer an Array containing myself". If the
receiver is a Collection and you want this new semantics, one has to write
"Array with: self" again. That's not polymorphism IMHO. And it's possible to
introduce bugs in situations where the receiver of #asArray can be either a
Collection or another kind of object because it's not clear if you expect
the result to be an Array containing the receiver in all cases or not. Also,
this may cover bugs where one does not expect non-Collections to be a
receiver of #asArray - it would just continue to work where it shouldn't.

Does the ANSI Smalltalk standard say anything about #asArray?

Joachim Geidel

On 20 June 2010 12:21, Joachim Geidel <[hidden email]> wrote:
+1.

#asArray for non-collection types is ambiguous.

> Joachim Geidel
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Hi,

> maybe #inArray or #asSingleton would be more appropriate: it is not a
> conversion, it is an encapsulation.

Nope, Chris is right. #asArray (and #asCollection) belong in Object and add a
lot to promoting terseness in Squeak.

Since Smalltalk does not support multi-methods, it is essential that the
caller of a method can pass arguments in multiple formats to the same method
and have them correctly interpreted by the implementation.

Remember- the computer works for the user, not the other way around.

For those interested in a pattern, the Chronology implementation uses
#asDateAndTime gratuitously , for similar _significant_ improvements in
terseness and readability.

I find it deeply offensive when using String>>#format: to _have_ to  make and
pass an array when my string only has one {1} subsctitution field. Silly little
languages like C# allow multi-methods.


Brent

One danger with this approach is that every different application may
have its own idea of how to convert some object into an Array.

For example (1@3) asArray could be {1@3} as well as #(1 3) for some
applications, simply because there is an argument I'd like to be both
a Point or a Collection...

I see some relation with this:
http://gbracha.blogspot.com/2010/06/patterns-as-objects-in-newspeak.html

Nicolas

2010/6/20 Brent Pinkney <[hidden email]>:

On 2010/06/20 15:16, Brent Pinkney wrote:
Smalltalk _can_ support multimethods - Foote/Noble/Johnson's work shows
how (http://www.laputan.org/reflection/ecoop-multimethods.pdf) - we just
don't make use of the feature.

(I assume you are talking about multiple dispatch - method lookup using
not just the receiver but also the types of the parameters to a
selector, like Common Lisp's generic functions?)

> Remember- the computer works for the user, not the other way around.
>
> For those interested in a pattern, the Chronology implementation uses
> #asDateAndTime gratuitously , for similar _significant_ improvements in
> terseness and readability.
>
> I find it deeply offensive when using String>>#format: to _have_ to  make and
> pass an array when my string only has one {1} subsctitution field. Silly little
> languages like C# allow multi-methods.

Do you have a reference for the C# part? I see a claim on Wikipedia
pointing to a page that doesn't talk about multiple dispatch, and the
"New Features in C# 4.0" on
http://code.msdn.microsoft.com/cs2010samples/Release/ProjectReleases.aspx?ReleaseId=1686 
also doesn't demonstrate (as far as I can see) multiple dispatch.

Hi,

On Sun, Jun 20, 2010 at 4:11 PM, Frank Shearar
<[hidden email]> wrote:
>> Since Smalltalk does not support multi-methods, it is essential that the
>> caller of a method can pass arguments in multiple formats to the same
>> method and have them correctly interpreted by the implementation.
> ...
> (I assume you are talking about multiple dispatch - method lookup using not
> just the receiver but also the types of the parameters to a selector, like
> Common Lisp's generic functions?)

looks more like varargs to me ...

Best,

Michael

Best reference about multiple dispatch can be found in Slate language.

http://files.slatelanguage.org/doc/pmd/ecoop.pdf

in short, it is not about varargs but about looking up for a method
based on a set of behaviors(objects) of message arguments.

in smalltalk a lookup function takes two arguments:

F(selector ,  receiver class)

with multiple dispatch a lookup function can take any number of arguments:

F(selector ,  receiver, arg1 , arg2 .. )

so, effectively, if method is unary, then you have a single dispatch,
as in smalltalk, since
arguments count == 1 (receiver is implicit argument), and if there are
more than 1 argument,
then lookup function using properties of every or subset of message
arguments to find a method.

On 20 June 2010 17:38, Michael Haupt <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

On 2010/06/20 18:32, Igor Stasenko wrote:
> Best reference about multiple dispatch can be found in Slate language.
>
> http://files.slatelanguage.org/doc/pmd/ecoop.pdf
>
> in short, it is not about varargs but about looking up for a method
> based on a set of behaviors(objects) of message arguments.

Yes, that was Michael's point - that what Brent's talking about is
possibly _not_ multiple dispatch.

frank

On 2010/06/20 16:38, Michael Haupt wrote:
I think you're right, Michael.

Objective-C's varargs look like this:

   NSString *s = [NSString stringWithFormat: @"a string %@, a float:
%1.2f", @"string", 3.1415];

Note the comma separated values there, in contrast to the more usual
keyword syntax like Smalltalk:

   [myObj aSelector: @"hello" withMultiple: 1 args: 2];

The varargs function exactly like &rest parameters in Common Lisp - a
list of values. So it sounds like Brent and Chris want those format
strings (or other vararg-using selectors) to behave the same way with a
single object as with a collection, where the single object is treated
as a single-element collection.

On the implementation side of such a "varargs" method, you'd have

   varargSelector: aCollectionOrObject
     ^ (aCollectionOrObject asArray) inject: 0 into: [:total :n | total
:= total + n].

instead of the rather uglier

   varargSelector: aCollectionOrObject
     | coll |
     coll := aCollectionOrObject isCollection
       ifFalse: [Array with: aCollectionOrObject].

     ^ (coll asArray) inject: 0 into: [:total :n | total := total + n].

In a library that has many vararg-like selectors, this can make a nice
improvement.

frank

> instead of the rather uglier
or, as it is used, the rather prettier:

   selector: things
     "a single Thing, or a collection of Things."

     ^ thing asCollection inject: 0 into: [:total :n | total := total + n].


Brent

On 2010/06/20 21:47, Brent Pinkney wrote:
>> instead of the rather uglier
> or, as it is used, the rather prettier:
>
>     selector: things
>       "a single Thing, or a collection of Things."
>
>       ^ thing asCollection inject: 0 into: [:total :n | total := total + n].

Yes, that is _rather_ prettier than what I'd written! I'll remember this
idiom.

In which case, my argument in defence of #asArray isn't much of a
defence at all.

frank

On 2010/06/20 22:30, Frank Shearar wrote:
I must be having a slow day or something. The idiom's nice & pretty...
and of course #asCollection doesn't exist. So what Chris is saying is
that this idiom is nice and pretty and we need Object>>asArray to make
it work.

frank

Op zondag 20 juni 2010 22:53:46 schreef Frank Shearar:
> I must be having a slow day or something. The idiom's nice & pretty...
> and of course #asCollection doesn't exist. So what Chris is saying is
> that this idiom is nice and pretty and we need Object>>asArray to make
> it work.

Actually, I wrote #asCollection and #asArray (and Object >> #, ) as part of
the same change set to get decent collection semantics into Object.

Chris - perhaps it makes sense to submit them as one ?

Brent

My sincere apologies Brent, I completely forgot about that change-set.
 I did not intentionally dissect your implementation.

I've just posted an updated Collections package with the entire
original change-set that now encompasses the full concept.  A mere six
methods bring the same useful extension of ExceptionSets to any
object.  Objects may be concatenated, as in:

  object1, object2 --> "{ object1. object2 }

and, also:

  { object1, object2 }, object3 --> "{object1. object2. object3 }"

It flattens API where collection-arguments are concerned..  Useful,
terse.  Gorgeous.  I support this.

 - Chris

On Sun, Jun 20, 2010 at 4:10 PM, Brent Pinkney <[hidden email]> wrote:

Then also:

Object1 , {Object2 . Object3} -> {Object1 . Object2 . Object3}

But then you might want to preserve argument species :
$a , ' mouse' -> {$a. ' mouse'}.
$a , ' mouse' -> {$a. $ . $m. $o. $u. $s. $e}.
$a , ' mouse' -> 'a mouse'.

Nicolas

2010/6/21 Chris Muller <[hidden email]>: