Seaside SqueakPortPlatformApp proposal

[TriSebastian]

Hi Seasiders!

I would like to propose a solution for upcoming Squeak ports.

For a lot of Squeak ports might need a XYZPlatformApp due to platform specific codings in classes wich might not be included in VASmalltalk 8.0, I expect a huge problem with all those parallel implementations.

Example:

GoogleChart has a implementation Color>>#fromString: aSymbolString within it's PlatformApp
Flotr has also a implementation of Color>>#fromString: aSymbolString within it's specific PlatformApp
If someone might already have loaded GoogleChart and tries to load Flotr in addition to that, he might get a load failed due to fromString: may only be defined by one of these....

That shouldn't be a problem for experienced VASmalltalkers, but for Newbies this might be a pain. And could even deter them from using VASmalltalk.

My suggestion on that issue would be the introduction of a CommunityPlatformApp. Everybody uses this application for portinglayer extensions. Result from this might be no duplicated codings and no confusion.

I know that next minor releases of VASmalltalk 8.0 will have additional base extensions,... but I don't think that instantiations will be able to support all wished functionalities needed for porting.

I can't actually say, if it might be needful to have a SqueakVASTCommunityPlatformApp next to a VWVASTCommunityPlatformApp and a DolphinVASTCommunityPlatformApp, or just one VASTCommunityPlatformApp ...

What do you think about that idea?!

[|]
Sebastian

[a3aan]

It must be one app otherwise the various platform apps will (soon) conflict with each other.

I can't actually say, if it might be needful to have a SqueakVASTCommunityPlatformApp next to a VWVASTCommunityPlatformApp and a DolphinVASTCommunityPlatformApp, or just one VASTCommunityPlatformApp ...

Cheers,
Adriaan.

[wembley]

Sebastian -

There are 2 cases to be handled:

1) GoogleCharts and Flotr both want a Color>>#fromString: method, but they need the method to have different semantics
2) GoogleCharts and Flotr both want a Color>>#fromString: method with identical semantics

The first case is nearly impossible to handle without renaming one of the method implementations or subclassing Color. However, the second case is easily handled using a technique that I will call optional extension subapplications. In fact, if you use this technique, you will not need to make any changes to your application if Color>>#fromString: ever ends up in the base code.

I will use the RBParserApp from V8.0 as an example. If you want to follow along, open an Application Editions browser and select the RBParserApp. Notice that this app has one subapp -- RBParserVAApp. This subapp contains the VA Smalltalk unique code for the parser.

Now switch the browser to the Subapplication Names view and select the RBParserVAApp. Notice that this subapp has 3 subapps of its own, all with names beginning with RBParserVAStub_. The remainder of the subapp name relates loosely to the extension method selector (for example, RBParserVAStub_rightArrow). These subapps contain no code -- they only server to anchor the extension and allow it to be optionally loaded.

Now select the RBParserVAStub_rightArrow in the Subapplication Names column. Notice that this subapp has just one subapp of its own -- RBParserVA_rightArrow. This subapp contains just one extension method -- Object>>#->. All the magic is in the configuration expression for this subapp. The expression is:

Code: Select all

(Object canUnderstand: #->) not or: [((Object>>#->) application name indexOfSubCollection: 'RB' startingAt: 1) == 1]

So, this subapp is loaded, supplying the extension, only if the extension method is not understood (meaning it does not already exist in the image) or if the extension method is provided by a (sub)app whose name begins with RB (to allow for reloading of the extension).

That's all there is to it -- pretty easy if you know how to do it (I learned this trick from Eric Clayberg many years ago).

[daswartz]

There are 2 cases to be handled: 1) GoogleCharts and Flotr both want a Color>>#fromString: method, but they need the method to have different semantics 2) GoogleCharts and Flotr both want a Color>>#fromString: method with identical semantics

The first case is nearly impossible to handle without renaming one of the method implementations or subclassing Color.

Or if VAST had full namespace support.

Doug Swartz

[skrishnamachari]

What is EsSmalltalkNamespace for..?

Is it non-trivial to support proper namespace with this...