Overrides to store hash of the original method?

Wouldn't it be cool if every override stored the hash of the original
method and notified you when loading onto a method with a different
signature (i.e. updated code)? I find myself reviewing all overrides of
base classes with every revision of VisualWorks and it might be helpful
if it was a little easier.

I better go hide somewhere because I suspect this will evolve into a
conversation about proper treatment of multiple overrides with regards
to ordering etc, then slowly become a rant about VisualWorks base image
containing many many many overrides in the shipping version, then slowly
boil down to native widgets again :D

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.

Okay, you are asking for it then,

Override overrides size

visual.im = 30
base.im = 5

Is this some kind of dissociative identity disorder? ;)

-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.
different
> signature (i.e. updated code)? I find myself reviewing all
overrides
> of
> base classes with every revision of VisualWorks and it might be
> helpful
> if it was a little easier.
>
> I better go hide somewhere because I suspect this will evolve
into a
> conversation about proper treatment of multiple overrides with
> regards
> to ordering etc, then slowly become a rant about VisualWorks
base
> image
> containing many many many overrides in the shipping version,
then

Travis,

That's pretty much spot on, although one way to do it right now would be
to tag the overriding method with <original: hash> at compile time where
hash is derived from a parse tree (tags included, comments excluded) of
the overridden method. Then just have the compiler check the hash again
at load to make sure that you're overriding original behavior that
hadn't been modified since.

I do like the idea of getting rid of Override and on a first glance it
doesn't seem like it would be that much tinkering, but yes, you'd still
need to add what I'm talking about and it doesn't appear that it would
be much different there. I'll poke around more on the way home today.

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.
different
> signature (i.e. updated code)? I find myself reviewing all
overrides
> of
> base classes with every revision of VisualWorks and it might be
> helpful
> if it was a little easier.
>
>
> Flippant posts aside. I want to make sure I understand what you're
really
> after. To do what you're after, a method would have to know _at
publish
> time_ that it was an override. I.e. it would be a different kind of
code
> entity than just a normal method. And having done so, you could add
info
> about what it was derived from. What you suggest in this case, is a
hash
> value, I assume derived from either the source, or the bytecode tree,
or
> the parse tree, or...?
>
>
>
> <Segue>I've been kicking around a different way of modeling overridden
> methods for a bit now. It basically involves getting rid of the
Override
> class and putting a minimal API on CompiledMethhod, and using
> AnnotatedMethods to build an in place linked list of methods. Then
> manipulating them is more direct. But I don't think this would really
> improve the situation for what you want if I understand correctly as
> described above.</Segue>
>
> It seems that the current system is a runtime overrides system.
Whereas
> what you want is compile time overrides. Is that a fair summary?
>
> --
> Travis Griggs
> Objologist
> 10 2 letter words: "If it is to be, it is up to me"
>