[Meta] Standard packages?

Me too.
Having good libraries that we can share would be really nice.

Stef

Because the code was not designed to be decomposed.
A registration mechanism may help there.

Stef

>> This could be the trigger for a new Preferences system. The  
>> current one
>> isn't that good, IMHO.

yes

Yes annotations can give a nice registration mechanism.

Now the key problem is should the code be loadable in 3.7....
I think that it should not. You cannot improve a system that should  
be backward compatible.
Look at mac. they discard regularly old support and add new ones.

Stef

Like in VisualWorks. Damien have a look at the example on the Pragma  
class

stef

On 23 juil. 07, at 12:21, Damien Cassou wrote:

On 23-Jul-07, at 23-Jul;3:21 AM, Damien Cassou wrote:

>
> - the preference system would have to browse all methods of all
> classes to detect these annotations
This turns out to be incorrect; you detect the notation during  
package loading. You have to load the package for the preference to  
be relevant, During the load you typically have to compile the method  
or otherwise scan it to make connections; at that point you clearly  
have an opportunity to deal with any pragmas, annotations, problems  
or chocolate.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Gargoyle (n.), olive-flavored mouthwash.

What if make things in such way, to allow different versions of same
package live in same image? And track dependencies between packages
using imports?

I discussed this idea on IRC channel with gulik (sorry cant recall his
name) about his namespaces project. I proposed to add 'imports' inst
var to packages.

Idea is simple:
- each package defined as a set of classes and methods.
- each reference to global name not declared it package itself, must
be declared in imported packages.

Only a few packages, like 'Kernel' don't require to import anything to
work. Others may require different set of packages to work.

All we need to change is a global lookup semantics: instead of looking
up the system dictionary, we should start looking for name from same
package , which contains the method.


On 23/07/07, Brad Fuller <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.

+1 (except I think traits are more like a protocol of what messages a class supports in tangible class form instead of only convention.  I expect the meta classes are still based on Behavior, no?)

---

PC Magazine’s 2007 editors’ choice for best web mail—award-winning Windows Live Hotmail. Check it out!

Andreas Raab <[hidden email]> writes:
> Brad Fuller wrote:
> > Instead of 'standard packages', what if there was an image
> > consisting of the fundamental classes required -- the basic building
> > blocks for all images.
>
> This is basically what we have today and it doesn't work. There is too
> much power concentrated in the hands of whoever "owns" that image; it
> *will* get abused for personal / project interests.

Yes, but we do have a messy political process for keeping anything
really perverse from happening.  That process can even be changed, and
surely your recommendations for such changes would have a whole lot of
weight.

Within the existing political process, the thing to do pronto is to
get someone on the Squeak Foundation Board, if you do not already have
someone sufficiently sympathetic.  Additionally, it never hurts to
keep an eye on the current release manager and communicate your
concerns to them, e.g. on which bug fixes to prioritize.


Aside from that, it has been a long stated goal of many volunteers to
separate Squeak into packages, and part of the reason is so that we
can have a non-controversial core and a non-controversial set of
optional but standard packages.  A lot has happened as part of the
3.10 release, as Ralph described.  Thus, the interest is certainly
here, if the technical details work out.


On the technical side, sharing packages would mean Croquet has to play
nice as an extension to a standard core and standard set of packages.
Small deltas from the standard component swould be fine, but big ones
will be a headache.  It looks like a tough engineering call on your
part.  Is the work of making Croquet sit on top of standard Squeak,
low enough that there is a net payoff from automatically inheriting
fixes to the standard image?


Lex

Lex Spoon wrote:
> Yes, but we do have a messy political process for keeping anything
> really perverse from happening.  That process can even be changed, and
> surely your recommendations for such changes would have a whole lot of
> weight.

I'm not interested in changing the way squeak.org operates; I'm only
interested in collaborating on particular packages (if there is mutual
interest).

> On the technical side, sharing packages would mean Croquet has to play
> nice as an extension to a standard core and standard set of packages.
> Small deltas from the standard component swould be fine, but big ones
> will be a headache.  It looks like a tough engineering call on your
> part.  Is the work of making Croquet sit on top of standard Squeak,
> low enough that there is a net payoff from automatically inheriting
> fixes to the standard image?

You are completely misinterpreting my intent. I am not planning to put
Croquet "on top of standard Squeak" (what exactly does that mean
anyway?) I have been looking for packages for which collaboration is
feasible, useful, and of mutual benefit.

Cheers,
   - Andreas