[vwnc] ObjectStudio 8.1 Dictionary>>os_at:
Locked
 
|
Hello folks,
I'm doing an inadvisable instant delurk, but I think it's important to get this message out as soon as possible. (In fact, James Robertson asked me to post this.) The issue deals with fairly fundamental behavior in ObjectStudio 8 Dictionaries.
I've been wrangling with Cincom folks over this issue. In short, in legacy ObjectStudio, Strings and Symbols are equal as Dictionary keys. (They are equal in other contexts, but we are being specific to this issue.) So in ObjectStudio, the following
expression:
(Dictionary new at: 'A' put: 1; yourself) at: #A
…returns 1 in ObjectStudio 7, but nil in ObjectStudio 8. This is an intentional move by Cincom towards the ANSI Smalltalk standard. However, it probably breaks a lot of applications, in many cases severely. In the case of the application I'm working
on, certain values are coming back from the Object-Relational code as Symbols instead of Strings. Other code is then doing dictionary lookups using these values, not finding the expected entries, resulting in the entirely different code execution paths. This
behavior produces no exceptions, and the Unit tests create mocks with the expected values as Strings, so they are not any help. Note that this is very much a runtime bug. As expected, there is no easy way to analyze this bug statically. The salient point
is that this decision to move towards ANSI Smalltalk behavior synergizes with Smalltalk's runtime type philosophy in particularly nasty ways. I think one can reasonably expect quite a large percentage of legacy ObjectStudio applications to be (often badly)
broken by this change, resulting in man-years of debugging time.
I believe that there is an efficient fix, however. Override Dictionary>>os_at:
os_at: key
^self
at: key
ifAbsent:
[key isString
ifTrue:
[key isSymbol
ifTrue:
[self
at: key asString
ifAbsent: [nil]]
ifFalse:
[self
at: key asSymbol
ifAbsent: [nil]]]
ifFalse: [nil]]
This override restores the original behavior in ObjectStudio 7. It also makes use of #ifTrue:ifFalse: and their ilk, so it exploits bytecode optimization to avoid message sends and produce fast JITed code. Using direct comparisons to classes might also
JIT more efficient code, but I'm not 100% sure. In any case, it would be nice if Cincom would adopt this code, though this would run counter to their desire to be ANSI compliant.
However, I think that there may be a way for Cincom to have their ANSI cake and eat it too. We can use such an override right now, but there is always the danger that some future change from Cincom might break this override, therefore breaking applications
depending on this behavior. However, Cincom is in a position to assure us they won't do this. If Cincom would agree to also run its Unit Tests against images with the above override, they can still have their ANSI story, but also provide assurance that customers
can continue to opt for backwards compatibility.
Somehow, there's something that bothers me about the tradeoff: have an ANSI bullet point vs. tons and tons of debugging for customers. To me, the scale tips heavily towards the latter. Avoiding this seems to me to be the customer-oriented choice. (And
hey, I'm even arguing *against* my own self-interest here. I'm getting paid to fix this now, and I could just quietly put in the override, hope that Cincom breaks it in the future, and come back and get paid even more.)
--Peter Kwangjun Suk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] ObjectStudio 8.1 Dictionary>>os_at:
|
|
Peter, The difference you point
out is by design of ObjectStudio 8. And the design is: Collection classes in
ObjectStudio 8 do not use os_equal:, but = as comparison message. This includes
Dictionary>at: and Collection>includes: We discussed this issue
in detail during the design phase of ObjectStudio 8. The main reasons for this
decision are
We know that this implies
that application code must be changed. For dictionary keys
normalizing the keys would be an option like (Dictionary new at: 'A' asSymbol put: 1; yourself)
at: #A Georg Georg Heeg eK, Dortmund
und Köthen, HR Dortmund A 12812 Tel. +49-3496-214328,
Fax +49-3496-214712 Von:
[hidden email] [mailto:[hidden email]] Im Auftrag von [hidden email] Hello folks, I'm doing an inadvisable instant delurk, but I think it's
important to get this message out as soon as possible. (In fact, James
Robertson asked me to post this.) The issue deals with fairly fundamental
behavior in ObjectStudio 8 Dictionaries. I've been wrangling with Cincom folks over this issue.
In short, in legacy ObjectStudio, Strings and Symbols are equal as Dictionary
keys. (They are equal in other contexts, but we are being specific to this
issue.) So in ObjectStudio, the following expression: (Dictionary new at: 'A' put: 1; yourself) at: #A …returns 1 in ObjectStudio 7, but nil in ObjectStudio
8. This is an intentional move by Cincom towards the ANSI Smalltalk
standard. However, it probably breaks a lot of applications, in many
cases severely. In the case of the application I'm working on, certain
values are coming back from the Object-Relational code as Symbols instead of
Strings. Other code is then doing dictionary lookups using these values,
not finding the expected entries, resulting in the entirely different code
execution paths. This behavior produces no exceptions, and the Unit tests
create mocks with the expected values as Strings, so they are not any
help. Note that this is very much a runtime bug. As expected, there
is no easy way to analyze this bug statically. The salient point is that
this decision to move towards ANSI Smalltalk behavior synergizes with
Smalltalk's runtime type philosophy in particularly nasty ways. I think
one can reasonably expect quite a large percentage of legacy ObjectStudio
applications to be (often badly) broken by this change, resulting in man-years
of debugging time. I believe that there is an efficient fix, however.
Override Dictionary>>os_at: os_at: key ^self at: key ifAbsent: [key isString
ifTrue:
[key isSymbol
ifTrue:
[self
at: key asString
ifAbsent: [nil]]
ifFalse:
[self
at: key asSymbol
ifAbsent: [nil]]]
ifFalse: [nil]] This override restores the original behavior in ObjectStudio
7. It also makes use of #ifTrue:ifFalse: and their ilk, so it exploits
bytecode optimization to avoid message sends and produce fast JITed code.
Using direct comparisons to classes might also JIT more efficient code, but I'm
not 100% sure. In any case, it would be nice if Cincom would adopt this
code, though this would run counter to their desire to be ANSI compliant.
However, I think that there may be a way for Cincom to have
their ANSI cake and eat it too. We can use such an override right now,
but there is always the danger that some future change from Cincom might break
this override, therefore breaking applications depending on this
behavior. However, Cincom is in a position to assure us they won't do
this. If Cincom would agree to also run its Unit Tests against images
with the above override, they can still have their ANSI story, but also provide
assurance that customers can continue to opt for backwards compatibility.
Somehow, there's something that bothers me about the
tradeoff: have an ANSI bullet point vs. tons and tons of debugging for
customers. To me, the scale tips heavily towards the latter.
Avoiding this seems to me to be the customer-oriented choice. (And hey,
I'm even arguing *against* my own self-interest here. I'm getting paid to
fix this now, and I could just quietly put in the override, hope that Cincom
breaks it in the future, and come back and get paid even more.) --Peter Kwangjun Suk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Georg,
As far as I know, adding the override I suggest makes
the hash issue irrelevant. This would make ObjectStudio 8 non
ANSI. However, my preferred proposal is that Cincom distribute the
base image ANSI compatible, but have some sort of token support
for overrides like this (call it "legacy configuration") to exactly
match legacy ObjectStudio behavior. This can be done simply by running the
Unit Tests a 2nd time with such overrides loaded, and just not doing anything
that will break them.
This is good for customers. While an ANSI
Smalltalk is desirable, it's not really a priority for a lot of
customers. They just want their apps to run now and they also don't want
their apps to break all over the place because of some future change Cincom puts
in. Customers can just put in overrides like this to preserve legacy
behavior, so their apps run now. Cincom unit testing against "legacy
configuration" protects them from such horrendous breaks in the future.
This is also good for Cincom. By doing this, you
get your ANSI story while keeping the bar as low as possible to upgrades to
future versions of ObjectStudio. The fewer technical hurdles there are to
sales, the easier sales will be.
--Peter
From: Georg Heeg [mailto:[hidden email]] Sent: Tuesday, June 16, 2009 1:22 AM To: Suk, Peter; [hidden email] Subject: AW: [vwnc] ObjectStudio 8.1 Dictionary>>os_at: Peter, The difference you
point out is by design of ObjectStudio 8. And the design is: Collection
classes in ObjectStudio 8 do not use os_equal:, but = as comparison message.
This includes Dictionary>at: and
Collection>includes: We discussed this issue
in detail during the design phase of ObjectStudio 8. The main reasons for this
decision are
We know that this
implies that application code must be changed. For dictionary keys
normalizing the keys would be an option like (Dictionary new at: 'A' asSymbol
put: 1; yourself) at: #A Georg Georg Heeg eK,
Dortmund und Köthen, HR Dortmund A 12812 Tel. +49-3496-214328,
Fax +49-3496-214712 Von:
[hidden email] [mailto:[hidden email]] Im Auftrag von
[hidden email] Hello
folks, I'm doing an inadvisable instant
delurk, but I think it's important to get this message out as soon as
possible. (In fact, James Robertson asked me to post this.) The
issue deals with fairly fundamental behavior in ObjectStudio 8
Dictionaries. I've been wrangling with Cincom
folks over this issue. In short, in legacy ObjectStudio, Strings and
Symbols are equal as Dictionary keys. (They are equal in other contexts,
but we are being specific to this issue.) So in ObjectStudio, the
following expression: (Dictionary new at: 'A' put: 1;
yourself) at: #A
returns 1 in ObjectStudio 7, but
nil in ObjectStudio 8. This is an intentional move by Cincom towards the
ANSI Smalltalk standard. However, it probably breaks a lot of
applications, in many cases severely. In the case of the application I'm
working on, certain values are coming back from the Object-Relational code as
Symbols instead of Strings. Other code is then doing dictionary lookups
using these values, not finding the expected entries, resulting in the entirely
different code execution paths. This behavior produces no exceptions, and
the Unit tests create mocks with the expected values as Strings, so they are not
any help. Note that this is very much a runtime bug. As expected,
there is no easy way to analyze this bug statically. The salient point is
that this decision to move towards ANSI Smalltalk behavior synergizes with
Smalltalk's runtime type philosophy in particularly nasty ways. I think
one can reasonably expect quite a large percentage of legacy ObjectStudio
applications to be (often badly) broken by this change, resulting in man-years
of debugging time. I believe that there is an efficient
fix, however. Override
Dictionary>>os_at: os_at:
key
^self at:
key
ifAbsent:
[key isString
ifTrue:
[key isSymbol
ifTrue:
[self
at: key asString
ifAbsent: [nil]]
ifFalse:
[self
at: key asSymbol
ifAbsent: [nil]]]
ifFalse: [nil]] This override restores the original
behavior in ObjectStudio 7. It also makes use of #ifTrue:ifFalse: and
their ilk, so it exploits bytecode optimization to avoid message sends and
produce fast JITed code. Using direct comparisons to classes might also
JIT more efficient code, but I'm not 100% sure. In any case, it would be
nice if Cincom would adopt this code, though this would run counter to their
desire to be ANSI compliant. However, I think that there may be a
way for Cincom to have their ANSI cake and eat it too. We can use such an
override right now, but there is always the danger that some future change from
Cincom might break this override, therefore breaking applications depending on
this behavior. However, Cincom is in a position to assure us they won't do
this. If Cincom would agree to also run its Unit Tests against images with
the above override, they can still have their ANSI story, but also provide
assurance that customers can continue to opt for backwards compatibility.
Somehow, there's something that
bothers me about the tradeoff: have an ANSI bullet point vs. tons and tons of
debugging for customers. To me, the scale tips heavily towards the
latter. Avoiding this seems to me to be the customer-oriented
choice. (And hey, I'm even arguing *against* my own self-interest
here. I'm getting paid to fix this now, and I could just quietly put in
the override, hope that Cincom breaks it in the future, and come back and get
paid even more.) --Peter Kwangjun
Suk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Georg Heeg
Let me make one correction: run the Units Tests a
second time, but leave out the tests for the specific "legacy" override methods
and run modified tests for those. The purpose is to catch side effects
from other changes which may break the legacy versions.
--Peter
From: Suk, Peter Sent: Tuesday, June 16, 2009 9:45 AM To: [hidden email] Subject: RE: [vwnc] ObjectStudio 8.1 Dictionary>>os_at: Georg,
As far as I know, adding the override I suggest makes
the hash issue irrelevant. This would make ObjectStudio 8 non
ANSI. However, my preferred proposal is that Cincom distribute the
base image ANSI compatible, but have some sort of token support
for overrides like this (call it "legacy configuration") to exactly
match legacy ObjectStudio behavior. This can be done simply by running the
Unit Tests a 2nd time with such overrides loaded, and just not doing anything
that will break them.
This is good for customers. While an ANSI
Smalltalk is desirable, it's not really a priority for a lot of
customers. They just want their apps to run now and they also don't want
their apps to break all over the place because of some future change Cincom puts
in. Customers can just put in overrides like this to preserve legacy
behavior, so their apps run now. Cincom unit testing against "legacy
configuration" protects them from such horrendous breaks in the future.
This is also good for Cincom. By doing this, you
get your ANSI story while keeping the bar as low as possible to upgrades to
future versions of ObjectStudio. The fewer technical hurdles there are to
sales, the easier sales will be.
--Peter
From: Georg Heeg [mailto:[hidden email]] Sent: Tuesday, June 16, 2009 1:22 AM To: Suk, Peter; [hidden email] Subject: AW: [vwnc] ObjectStudio 8.1 Dictionary>>os_at: Peter, The difference you
point out is by design of ObjectStudio 8. And the design is: Collection
classes in ObjectStudio 8 do not use os_equal:, but = as comparison message.
This includes Dictionary>at: and
Collection>includes: We discussed this issue
in detail during the design phase of ObjectStudio 8. The main reasons for this
decision are
We know that this
implies that application code must be changed. For dictionary keys
normalizing the keys would be an option like (Dictionary new at: 'A' asSymbol
put: 1; yourself) at: #A Georg Georg Heeg eK,
Dortmund und Köthen, HR Dortmund A 12812 Tel. +49-3496-214328,
Fax +49-3496-214712 Von:
[hidden email] [mailto:[hidden email]] Im Auftrag von
[hidden email] Hello
folks, I'm doing an inadvisable instant
delurk, but I think it's important to get this message out as soon as
possible. (In fact, James Robertson asked me to post this.) The
issue deals with fairly fundamental behavior in ObjectStudio 8
Dictionaries. I've been wrangling with Cincom
folks over this issue. In short, in legacy ObjectStudio, Strings and
Symbols are equal as Dictionary keys. (They are equal in other contexts,
but we are being specific to this issue.) So in ObjectStudio, the
following expression: (Dictionary new at: 'A' put: 1;
yourself) at: #A
returns 1 in ObjectStudio 7, but
nil in ObjectStudio 8. This is an intentional move by Cincom towards the
ANSI Smalltalk standard. However, it probably breaks a lot of
applications, in many cases severely. In the case of the application I'm
working on, certain values are coming back from the Object-Relational code as
Symbols instead of Strings. Other code is then doing dictionary lookups
using these values, not finding the expected entries, resulting in the entirely
different code execution paths. This behavior produces no exceptions, and
the Unit tests create mocks with the expected values as Strings, so they are not
any help. Note that this is very much a runtime bug. As expected,
there is no easy way to analyze this bug statically. The salient point is
that this decision to move towards ANSI Smalltalk behavior synergizes with
Smalltalk's runtime type philosophy in particularly nasty ways. I think
one can reasonably expect quite a large percentage of legacy ObjectStudio
applications to be (often badly) broken by this change, resulting in man-years
of debugging time. I believe that there is an efficient
fix, however. Override
Dictionary>>os_at: os_at:
key
^self at:
key
ifAbsent:
[key isString
ifTrue:
[key isSymbol
ifTrue:
[self
at: key asString
ifAbsent: [nil]]
ifFalse:
[self
at: key asSymbol
ifAbsent: [nil]]]
ifFalse: [nil]] This override restores the original
behavior in ObjectStudio 7. It also makes use of #ifTrue:ifFalse: and
their ilk, so it exploits bytecode optimization to avoid message sends and
produce fast JITed code. Using direct comparisons to classes might also
JIT more efficient code, but I'm not 100% sure. In any case, it would be
nice if Cincom would adopt this code, though this would run counter to their
desire to be ANSI compliant. However, I think that there may be a
way for Cincom to have their ANSI cake and eat it too. We can use such an
override right now, but there is always the danger that some future change from
Cincom might break this override, therefore breaking applications depending on
this behavior. However, Cincom is in a position to assure us they won't do
this. If Cincom would agree to also run its Unit Tests against images with
the above override, they can still have their ANSI story, but also provide
assurance that customers can continue to opt for backwards compatibility.
Somehow, there's something that
bothers me about the tradeoff: have an ANSI bullet point vs. tons and tons of
debugging for customers. To me, the scale tips heavily towards the
latter. Avoiding this seems to me to be the customer-oriented
choice. (And hey, I'm even arguing *against* my own self-interest
here. I'm getting paid to fix this now, and I could just quietly put in
the override, hope that Cincom breaks it in the future, and come back and get
paid even more.) --Peter Kwangjun
Suk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |