[Vm-dev] re: deployment components (was "The Dilemma: Building a Futuristic GUI for Ephestos")

Eliot Miranda eliot.miranda at gmail.com
Wed Sep 24 17:33:15 UTC 2014


Hi Torsten,

On Wed, Sep 24, 2014 at 1:16 AM, Torsten Bergmann <astares at gmx.de> wrote:

>
> Craig Latta wrote:
> >Right, there's no need for anyone to use UUIDs when referring to
> >classes in Smalltalk expressions.
>
> Yes, exactly this. We still use regular names for the classes - but for
> the tools
> they have a distinguishable ID.
> Best is to use a UUID for the ID as it is unique from the beginning. So if
> you
> create a class "Foo" and I create one both are unqique by ID - even when
> using
> the same name.
>

But this doesn't cope with the fact that I can take a copy of your class,
modify my copy by adding or changing a method, etc, and hence derive two
different versions of the class with the same UUID. If a class is defined
by what it is (its methods, instance variables, superclass, etc) then it
doesn't need a UUID.  Its own form uniquely (and reliably) identifies it.
If you use UUIDs then is the UUID modified every time some modification is
made to it?


The "rest" is implemeting tooling support. When you write "Foo" in a
> workspace
> then the workspace either already has a naming context to resolve the name
> (see [1]
> or could provide you with a selection if there is more than one.
> Internally you could
> bind to the right class by using the ID.
>

That's what namespaces do.


> I hate prefixing the classes as we now do, I want to name the classes
> "Instruction"
> not "IRInstruction" in Opal or "AJInstruction" in AsmJIT, especially since
> "IR" and "AJ"
> do not really tell you anything. Smalltalk names should be understandable.
> Additionally
> we should have meaningfull (and also unique) names also for namespaces.
>

Agreed.

Also the current three/two letter prefixing of classes that is used in
> Squeak or Pharo
> only scales well for small communities...
>

It's horrible.  Crappy.  But we're in the process of transitioning to
namespaces and that will change things.


> When there are things I like in Java then it is the fact to use reverse
> domains
> for namespaces. It is easy, understandable and I could also easily check
> if there
> is a web location.
>
> This way a namespace "org.apache.maven" gives you something meaningful, I
> can even
> visit http://maven.apache.org/. Allows the community to easily scale with
> thousands of
> classes without having clashes.
>
> Think of "org.pharo.asmjit.Instruction" vs "org.pharo.opal.Instruction"
>

You should read the Newspeak stuff on namepsaces.  This explicit wiring is
horrible.  It doesn't allow us to mix and match as we want to.



> So you additionally need better and meaningful namespaces THAT SCALE AND
> ARE EASY TO UNDERSTAND
> combined with real packages (as objects, as Pharo already has).
>

+1.


Then we also need ABIA (Around, beginner, inner, after messages),


I don't see what this has to do with distribution and you haven't given any
rationale for it. For me super is enough.  One can synthesize all the
others using it (except I guess inner; can you give me an example of
inner?).  In any case one can synthesise code via editing without needing
new VM machinery.  So I'm most dubious about this.

I *do* recall discussing and sketching with David Leibs something of this
flavour for loading packages.  For example deploying some Smalltalk
component/service might require modification of some core method, e.g.
add/remove dependents, and that the edit would be better expressed as a
pattern where the existing method is filled out in an element of a template
of the replacement to be loaded.  This is to do with being able to define
finer-grained overrides, and have them removed after.  IMO this is more
general, powerful and easier to manage than using new VM machinery.



> multiple method
> categories,


What's the rationale here? Arguably we have this now but there are bugs in
ClassOrganizer and the tools.  But it is something you could write tests
for and fix now.  But it seems kind of trivial and beside the point of
deployment.  Can you explain why it is important?


> selector namespaces, possibility for visibility (like private methods, see
> [2]),
>

agreed.  These, at least in theory, are a very nice way of insulating
extensions.


> unified annotations for classes/methods/variables and a few other
> ingredients from my
> personal wishlist and it may shape a different new future...
>

Annotations indeed.  But I think first-class slots are more important no?
And the Pharo folks have a working system which we can use.



> The interesting part is not to add all kind of stuff to Smalltalk - the
> interesting
> part is what is the most minimalistic system to allow for something
> extensible
> and still flexible (even within the meta-system) so that one can bootstrap
> things on top.
>

Right.  So ABIA seems over the top.  What does one *really* need?  You talk
of "my personal wishlist" and at the same time of "the most minimalistic
system".  This reads to me as "my personal grab bag" and "the most
minimalistic system".  Decide :-).



>
> Bye
> T.
>
> [1] http://vimeo.com/75391990
> [2] http://smalltalkhub.com/#!/~CamilleTeruel/PrivateMethods
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140924/5e7e5d94/attachment-0001.htm


More information about the Vm-dev mailing list