Fun with the Dictioanaries

Hello All,

In my application I have few dictionaries which I actually use as
Dictionary to do simple translations of some external information into
more readable format.

such as $0 ->'off'
        $1 ->'on'
        $2 ->'old'
        .......

So when DLL reports back 1 I know to show 'on' on some UI.

To my surprise the opposite to the Dictionary at: i.e.
keyAtValue:aString does not work for me. After looking at the code for:

keyAtValue: value ifAbsent: exceptionBlock
        "Answer the key whose value is identical to the argument, value.
        If there is none, answer the result of evaluating exceptionBlock."

        self keysAndValuesDo:
                [:aKey :aValue | value == aValue ifTrue: [^aKey]].
        ^exceptionBlock value

They use identity which in my case never finds anything, as in VW 'foo'
= 'foo'  evaluates to true, but 'foo' == 'foo' is false.

Did anybody have that same issue and does anybody thinks that it might
be something missing in here?

I can change my dictionary to contain symbols instead of strings, but
that would require a lot of #asString transformations and would create a
lot of unneeded symbols.

Or as I am about to create a method similar to the above but with
equality check.

Any Ideas ?

--Mark

#keyAtValueEqual:
#keyAtValueEqual:ifAbsent:

These live in 'Com- ExtensionsToBase',

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
for:
>
> keyAtValue: value ifAbsent: exceptionBlock
> "Answer the key whose value is identical to the argument, value.
> If there is none, answer the result of evaluating
exceptionBlock."
>
> self keysAndValuesDo:
> [:aKey :aValue | value == aValue ifTrue: [^aKey]].
> ^exceptionBlock value
>
> They use identity which in my case never finds anything, as in VW
'foo'
> = 'foo'  evaluates to true, but 'foo' == 'foo' is false.
>
> Did anybody have that same issue and does anybody thinks that it might
> be something missing in here?
>
> I can change my dictionary to contain symbols instead of strings, but
> that would require a lot of #asString transformations and would create
a
> lot of unneeded symbols.
>
> Or as I am about to create a method similar to the above but with
> equality check.
>
> Any Ideas ?
>
> --Mark

Thanks Boris,

Here is another complaint about VisualWorks as IDE -- It' arbitrary
partitioning of the code base and extensions.

THere are whole lot of very nice and very useful extensions to the base
classes available from the vendor in various "add on" packages, the one
bellow is the perfect example of this.  And it was available for a while.

Also of note, Com -Win32 does contain a lot of useful code to access
Win32 services.  I never needed to use the Com, and I never developed
with it. I gave it  a try once or twice long time ago.  Recently, I did
take a fresh look at Com - Connect, and did not feel happy for simple
reason: they already have many functions I am using in my application
and had to develop myself, or get from what other people contributed.

My point being: if me and others new that that code already existed a
lot of time would be saved and more Smalltalk Applications would be
delivered.

Just a rant.

-Mark

Boris Popov wrote:
> #keyAtValueEqual:
> #keyAtValueEqual:ifAbsent:
>
> These live in 'Com- ExtensionsToBase',
>
> Cheers!
>
> -Boris
>

What would you suggest though?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
base
> classes available from the vendor in various "add on" packages, the
one
> bellow is the perfect example of this.  And it was available for a
while.
>
> Also of note, Com -Win32 does contain a lot of useful code to access
> Win32 services.  I never needed to use the Com, and I never developed
> with it. I gave it  a try once or twice long time ago.  Recently, I
did

>>> Here is another complaint about VisualWorks as IDE -- It' arbitrary
>>> partitioning of the code base and extensions.
> What would you suggest though?
>


Semantic clustering comes to mind, I'm sure that with some tweaks a  
great companion tool for Store and parcel directories can be built.

The core is already implemented by the Moose team :-)

http://www.iam.unibe.ch/~akuhn/indexcgi/talk_WCRE2005.pdf


R
-

Another approach would be that Cincom goes through at least these "Extensions to Base" packages that exist for several (visualworks)
projects/solutions and decides to include them into the base.

There are some extensions for Com, some for Opentalk, some for others. Many of them could be integrated into the base to avoid the
"invent each time" syndrom.
Not to speak about the extensions that are developed outside Cincom. There once was an effort to collect them in the public store.
Many of them would also be worth a look.

Some positive effects would result from some cleanup by reassigning code to different parcels in general:
There is the question why the classes Note and Assert are "COM Code annotations" and not basic "Code Annotation". It was used by the
COM project, but is of general use. So you won't find it if you don't need COM.
COM also has many things useful for native Win32 access. So it would rather belong to OSSystemSupport (which could be enhanced
anyway)?
There are many stream writing extensions.
There would be plenty of similar cases.

I see the problem that there is much code out there you won't find if you don't know where to search for it. This holds not only for
the public store, but even the distribution parcels. And you have to include zillions (ok, not yet) of extension parcels and
contributed parcels that I would call mandatory to get to the starting point. And with each parcel and contribution of extensions,
the risk of conflicts or incompatibilities rises. And I want to build my own application and not deal with that.

The only negative effect I see with this integration project is that there would be - only once - some conflicts with the extensions
everyone wrote for themselves. But I assume they merge easily because everyone invented the same. And you gain because of a smaller
code base you have to maintain and port with each version and you don't need to check for conflicts each time.

Just my 2c

Thomas

Hello Thomas,

Thomas Brodt schrieb am 08.03.2007 10:05:
> Another approach would be that Cincom goes through at least these
> "Extensions to Base" packages that exist for several (visualworks)
> projects/solutions and decides to include them into the base.

Yes, this would be a good idea. It could also be done with relatively
low effort if it's done stepwise for a few packages per release cycle.
BTW, although I don't actually browse changes between base images, I
have the impression that this actually happens already. Now and then, I
stumble across methods in base classes which I missed in previous VW
releases. :-)

> Not to speak about the extensions that are developed outside Cincom.
> There once was an effort to collect them in the public store.
> Many of them would also be worth a look.

While I agree that it would be very helpful to have at least some of the
contributed extensions in the base image, there may be legal issues.
Some of the components do not have any licensing information attached,
some come with various open source licenses. There may be licensing and
liability risks associated with integrating them, as their source is
sometimes unclear.

Concerning the tools, it may also be a resource problem, with
The-GUI-framework-formerly-known-as-Pollock coming really-soon-now and
the foreseeable need to migrate the development tools. How much effort
should Cincom invest in integrating third-party contributions,
clarifying licensing and liability issues etc. for Wrapper based tools?
Would it be better to leave them as they are, and develop the next
generation of tools on the basis of Widgetry?

Let's see what the Cincom Smalltalk team comes up with after their
current meeting
(http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3350634448).

Best regards,
Joachim Geidel

> Concerning the tools, it may also be a resource problem, with
> The-GUI-framework-formerly-known-as-Pollock coming really-soon-now and
> the foreseeable need to migrate the development tools. How much effort
> should Cincom invest in integrating third-party contributions, [...]
>  


During the Packaging BOF at StS there was the proposal to create a
'repackaging' of VW outside of Cincom.
At the time there was some support for that idea (but I am in the
skeptics camp: I question the longevity of such an unfunded community
project if you want me to use it in production sw).
IIRC Charles Monteiro was the principal proponent of that idea (please
correct me if I'm wrong).


R
-