loose methods: Smalltalk asPython

[Jan Theodore Galkowski]

>> > We've not had an excellent dynamic OO language since
>> > Smalltalk, IMO.
>
>I would say that "excellence" in object oriented programming is not a
>strong design goal of Python.  Python tries to support OOP well, but
>not to enhance OOP to the detriment of other, more important goals.

okay.  no quibble with that.  noone said "excellence" was my goal.  it
was a description of Python.   if excellence in that direction were my
goal, i'd probably head Eiffel's way.  i have tried that out.  i don't
like it, although it has some great ideas in it.

>
>> >Guido was opposed to modifying builtin types before Java existed.
>> >It's similar to his opposition to dynamic syntax.
>>
>> Opposition or not, the language definition is there.  Surely
>> Smalltalk's OO style can be respected.  Smalltalkers have been
>> doing OO in a dynamic context longer than many.  There are things
>> to learn there.
>
>Well, that Smalltalk and Ruby do this at least suggests that it won't
>be the end of the world as we know it if it were to happen in Python.
>Personally, I'm with Guido here.  Allowing this might make Python's OOP
>more "excellent", but it would be to the detriment of other, more
>important goals, like minimizing surprise.

okay.

>
>> There are two things here that need to be kept straight, I think.
>>
>> One is the primacy of builtin types.
>>
>> The other is placing those builtins at the top of their own object
>> hierarchy.  Is "int", properly speaking, a descendent of "object"?
>> No, it's the root of its own tree.
>
>Are you saying that it shouldn't be a descendant of "object", or that
>it isn't?  "int" is certainly a subclass of "object" in Python (as are
>all objects).

i stand corrected and, as a result of your assertion, discovered the
"super(.,.)" built-in. thanks.  i'll have to think about good ways to
use that, that is, other than involving it in some kind of case logic.

>
>> Smalltalk has "int" as well, as a *subclass* of Number.  It's
>> primitive.
>
>Number is primitive?  I thought all types in Smalltalk had a common
>base type.

no.  it was my poor phrasing.  my "It" was intended to refer to "int"
not "Number".

>
>Anyways, Python 3000 is exploring the idea of an abstract hierarchy
>that has classes (interfaces?) like Number and Sequence.  In fact, I
>even saw some talk about somehow being able to retrofit classes to
>support one of these interfaces/ABCs, though it was pretty conjectural.

well, and surely Python has the additional challenge of being brave
enough to tackle multiple inheritance, something Smalltalk could not do,
not directly.

>
>> In any case, as respectful of Mr/Dr van Rossum as I am, simply
>> because so-and-so says something is bad and therefore it must be true
>> is a fallacious response.
>
>The same could be said of Smalltalk, i.e., because Smalltalk does it
>therefore it is good is just as fallacious.

never said that, either.  Smalltalk is not a person.  my justification
for loose methods is what you can do and build with them, not simply
that they' in Smalltalk or Ruby.

i don't see programming languages as primary.  i see programming and
design styles as primary.  as i've remarked in a separate comment, if i
can eck out a niche within a language which permits me to express a
useful, perspicuous style, i'm happy.

that's all.

>
>Regardless, whatever Guido pronounces is what happens.  If he's
>adamantly against something, it's pretty much an academic discussion.
>

and, as i've also remarked, i'm not interested in having Python changed
or proposing it be changed.  because i'm simply seeking kindred spirits
who might have examined how to go about realizing loose methods in
Python does not at all mean i want the language somehow "fixed" to make
it just like Smalltalk.

right now, i'm just seeing how far i can take the language as it is and
what can be done with it, especially what is probably a subset.  i'm
very pleased with the adventure.

and, as i've said in that other post, i'm also pleased with NumPy, since
poor numerical support is something Smalltalk always suffered from,
although there is

  http://www.abebooks.com/servlet/SearchResults?sts=t&y=0&kn=smalltalk+java+numerical+methods&x=0