[ANSI-Smalltalk] Protocol extensions - Object

[Richard A. O'Keefe]

I've been building a "batch compiler" for Smalltalk
in my spare time for a couple of years.  One of the
reasons I did this was to explore the ANSI Smalltalk
standard.  This has perhaps given me a different
perspective from other people on this mailing list,
because I think a "static Smalltalk" is actually a
useful tool.

The STEP entitled "Protocol extensions - Object"
lists three kinds of methods:

  - fairly trivial control structure operations.

    I have no quarrel with those.

  - become:

    My system doesn't have it and doesn't need it.
    On a 2+GHz Intel Core Duo Mac, brand X Smalltalk
    took 3 usec per become:, while brand Y took 300 usec.
    Squeak 3.10 core has 25 senders of #become:, four of
    which are tests of #become:.  Of the rest, the only
    one that would be relevant in my system is in a data
    structure I already implemented years ago without
    #become:.  The utility of #become: in implementing
    the Smalltalk environment _in_ Smalltalk is clear,
    and I would imagine that the utility of the Smalltalk
    environment is beyond dispute.  But is its
    _necessity_ so?  Are fully interactive self-hosting
    Smalltalks the only desirable Smalltalks?

    Just as the ANSI C standard listed tree-argument main()
    as a common extension, it would be fair enough for a
    new Smalltalk standard to list #become: as a common
    extension.  I'd be sorry to see it in the core, though.

  - instvarAt: and instvarAt:put:

    These are similar to become: in that they have
    legitimate uses in implementing the Smalltalk
    environment.  There are things like pickling where
    it is hard to do without them.  (I have tried, and
    since I [will] compile to C [if/when the compiler is
    finished]) I have a back door I can use instead.)

I think it might be worth splitting that STEP, and any
others like it, into a "traditional low level hacks that
are really really useful for building a Smalltalk system"
STEP and "nice stuff for straightforward applications"
STEPs.





On 5 Sep 2008, at 7:23 pm, Bruce Badger wrote:

> Richard,
>
> We don't seem to have a Step addressing Time as yet:
>
>  http://smalltalk.gnu.org/step/steps-smalltalk-enhancement-proposals
>
> Would you be willing to lead the creation of one?
>
> All the best,
>    Bruce
>
> 2008/9/5 Richard A. O'Keefe <ok at cs.otago.ac.nz>:
>> What I'm really concerned about is things like the
>> DateAndTime class, where the ANSI specification
>> appears to be unimplementable.  There are two
>> conflicting requirements: we must be able to do
>> arithmetic on these timestamps, and they must be
>> in UTC. This requires the ability to predict leap
>> seconds for hundreds of years in advance...
>
> -- 
> Make the most of your skills - with OpenSkills
> http://www.openskills.org/
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
>
> ====================================================================
>                     Auto Generated Mail Footer
>      If this email is requesting your password then it is a HOAX.
>                     DO NOT reply to the email.
>                    Validate this footer at the
> Otago University web site keyword search: information security phish
> ====================================================================
>
>
>

--
If stupidity were a crime, who'd 'scape hanging?