Contributing to Redline: source organization and class hierarchies

With a desire to learn more about Redline and Smalltalk in general, I thought it would be a good exercise to try and contribute to Redline.  In the source repository's OBJECTS-AND-PROTOCOLS document [1], the listing is what I understand to be based on the Smalltalk-80 'blue book' [2], which makes sense as a starting point.

I have some questions:

1.  Does this hierarchy have to be exactly as defined in the document?

For example, the document lists Date as a direct subclass of Magnitude (per Smalltalk-80):

Object
  |-- Magnitude
    |-- Date

but Pharo's Date class is a subclass of Timespan, which is in turn a subclass of Magnitude:

Object
  |-- Magnitude

    |-- Timespan

      |-- Date

Pharo clearly does this for consolidating things in a more convenient way, and to leverage certain things in various implementations.

As an introductory exercise, I want to help with the Date class/protocols, it'd be far easier for me to port what I can from Pharo.  Are we free to do this for Redline?  

My personal desire is that I would hope to do that, as this is in the spirit of Smalltalk extensibility, and is still polymorphically compatible with the Smalltalk-80 specs.  

Thoughts?

2.  Where would all of this reside in the project's source tree?

It seems odd that _everything_ defined in Redline would be in one huge package.  (I actually think that everything in st.redline.core should be moved to st.redline as 'core' seems like an arbitrary segmentation).

As we are to converge on the Smalltalk-80 feature set, where should these (and future classes) reside?

In Pharo for example, you see many Categories (i.e. packages): Kernel-Objects, Kernel-Chronology, etc, but you see no such parallel in Redline currently.  It seems logical to replicate this structure as packages in Redline, e.g. st.redline.chron.*, st.redline.coll.* (collections), st.redline.io.*, etc.

Thoughts?

Thanks for feedback,

Les

[1] https://github.com/redline-smalltalk/redline-smalltalk/blob/master/OBJECTS-AND-PROTOCOLS
[2] http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

We welcome your contributions, and please try to have tests around your work.

SUnit is being ported as we speak but the general asset library used in other tests
should get you under way.

>>1.  Does this hierarchy have to be exactly as defined in the document?

No the hierarchy does not have to be exact. The Blue Book is a starting minimal set.

You can and should add the intermediate subclass between Magnitude and Date.

What you should not do is copy the Pharo source verbatim but implement those methods
in 'Blue Book' Date class by looking at the Pharo implementation and following that.

The idea is that if Pharo has a Date 'foo' method but the 'Blue Book' does not then we need
to understand the need for this additional method. Focus is on a minimal workable
implementation.

>>2.  Where would all of this reside in the project's source tree?

Currently there are two packages in Redline, one for core (st.redline.core) and one for Stout (st.redline.stout).
The st.redline.core package is analogous to java.lang.* and therefore automatically included by the
compiler. You don't need to specify 'import:' for anything in this package.

There will be other packages as part of Redline.

You should put the Timespan class in the same place as Date.st and DateTest.st in the same place as
ObjectTest.st

I will bring up the idea of mirroring the Pharo Category as a Redline structure.
1st goal is to get the Runtime there and tested.

Your involvement is exciting and I appreciate the questions you are asking.
It is through your questions and use that Redline will improve.
Please keep the questions coming.

We welcome your contributions, and please try to have tests around your work.

There is no 'try' for me (personally) on this one.  If you're not writing tests when using a dynamic language, you might as well not use a dynamic language - you'll just be shooting yourself in the foot, IMO.  

And at the foundational level like Redline core, I'd personally feel uncomfortable with anything less than 98% line coverage (dunno how I'd evaluate that for Redline, but you get my idea).  When Redline end-users depend on this stuff at such a fundamental level, it's not fair to them to shoot for anything less IMO.

 

SUnit is being ported as we speak but the general asset library used in other tests
should get you under way.

Nice!  I look forward to that.

 

>>1.  Does this hierarchy have to be exactly as defined in the document?

No the hierarchy does not have to be exact. The Blue Book is a starting minimal set.

You can and should add the intermediate subclass between Magnitude and Date.

What you should not do is copy the Pharo source verbatim but implement those methods
in 'Blue Book' Date class by looking at the Pharo implementation and following that.

I think verbatim copying - where it makes sense, and not blindly - should be allowed.  This is completely 'legal' with and in the spirit of the MIT license.  We just need to be good citizens and give credit where it is due.

That is, if Pharo sends a message to object A, and that object is not needed in Redline, then you shouldn't copy.  But if the component is in Redline, and satisfies a Blue Book spec, there is no reason not to copy it verbatim IMO.  The name of the game here is getting a working version as fast as possible as long as we retain MIT license compatibility, no?

Again, I'm not talking about blind copying - just only if you've critically analyzed the problem set and it still makes sense to do so...

 

The idea is that if Pharo has a Date 'foo' method but the 'Blue Book' does not then we need
to understand the need for this additional method. Focus is on a minimal workable
implementation.

Totally agree. 

>>2.  Where would all of this reside in the project's source tree?

Currently there are two packages in Redline, one for core (st.redline.core) and one for Stout (st.redline.stout).
The st.redline.core package is analogous to java.lang.* and therefore automatically included by the
compiler. You don't need to specify 'import:' for anything in this package.

There will be other packages as part of Redline.

You should put the Timespan class in the same place as Date.st and DateTest.st in the same place as
ObjectTest.st

I will bring up the idea of mirroring the Pharo Category as a Redline structure.
1st goal is to get the Runtime there and tested.

Sounds good - thanks.

 

Your involvement is exciting and I appreciate the questions you are asking.
It is through your questions and use that Redline will improve.
Please keep the questions coming.

Thanks for the encouragement - I hope to help in whatever capacity I am able (and where time allows).

Cheers,

Les