[Glass] Simple questions while migrating code to GemStone (compatibility issues)

[Dale K. Henrichs]

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: glass at lists.gemtalksystems.com
| Sent: Wednesday, November 13, 2013 10:25:59 AM
| Subject: [Glass] Simple questions while migrating code to GemStone
| (compatibility issues)

| Hi guys,

| I continue trying to make my app work in GemStone. I am making
| progress, but I still have some questions:

| - Is there a way to print closures? When I inspect one I get
| something like "anExecBlock1" but I cannot see the source of the
| closure (not even the decompiled version).
I've submitted an issue against tODE for this[1]. As a workaround you can send the message #_sourceString to the block to get it's source ... 

[1] https://github.com/dalehenrich/tode/issues/52 

| - In Pharo I can parse a Date from this pattern: 'yyyy-mm-dd' with
| #readFrom. In GemStone I need to do: Date fromString: '2013-06-21'
| usingFormat: #( 3 2 1 $- 1 1). Which is the easies way to deal with
| this? Like the rest, delegating to a my own util class with 2 impl?
I think that the first order answer is that we should port the Pharo implementation to GLASS ... this would entail update the GsSqueakCommon package in the glss repo[2] with the appropriate implementation (fork repo and then issue a pull request when finished) including the Pharo tests for the feature ... 

In poking around in the image, I've found that SpDate class>>parseDateFromISO8601Stream: (from Sport) parses dates of the form you are looking for. Sport is ported to both GemStone and Pharo so that could be an option ... 

Finally you could create your own utility layer with common messages ... 

My preference is that the Pharo-style get ported to the compat layer in GemStone so others can benefit from the work ... hopefully moving GLASS up to github will make the chore of adding code to the compat layer easier than it has been in the past ... 

[2] https://github.com/glassdb/glass 

| - Do we have an alternative for WeakValueDictionary?
In 3.x we have KeySoftValueDictionary which is the moral equivalent of WeakValueDictionary with the caveat that instances of KeySoftValueDictionary cannot be persisted ... we only suppor vm level weakness ... 

| - I really miss the #split: and #join: methods. Maybe these could be
| ported to GemStone? Or are there similar methods already?
I'm not familiar with split:/join: but would be in favor of having them added to the compat layer. It looks like #split: has been added to the pharo compat layer in the GsPharo-Core package on GemSource[3] ... I think that I should move the GsPharo* packages onto the github repository to make it easy to contribute ... 

The GsSqueakCommon* packages are for methods and classes that have identical implementations on both Squeak and Pharo. there are GsPharo-* and GsSqueak-* packages for methods and classes that are unique to each platform ... 

If you are interested in adding #join: support, I'll move the GsPharo-* packages to the github repo ... 

Dale 

[3] http://seaside.gemtalksystems.com/ss/PharoCompat.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131113/eff696ee/attachment.html>