[vwnc] Store extensions

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Paul

 

You wrote:

---

I don't doubt that a port to a Store-enabled image would need variances

because there are fundamental changes in how methods relate to repostory

code. It isn't that it can't be done but just that it would be done differently.

VW already comes with good enough override support anyway.

---

 

Well, the situation I previously described, renaming an ivar, is currently

a problem with how VW manages overrides. If you rename an ivar after

overriding a method that refers to the ivar, you will end up with an

entry in the Undeclared dictionary.

 

I brought it up because it appeared to me that your description would

have similar difficulty because you keep the compiled method rather

than just the source of the overriden method.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

---

From: Paul Baumann [mailto:[hidden email]]
Sent: Thursday, November 20, 2008 2:38 PM
To: 'Terry Raymond'; [hidden email]
Subject: RE: [vwnc] Store extensions

 

Override support benefits developers that need to modify code provided by others. "you" would not be modifying an *overridden* method because then you are the maintainer of the code and didn't need an override. I gave examples where a tool provider modified code that you had existing overrides of--the scenario that is relevant to overrides and the possibility of renamed inst vars.

 

I'm not sure where we are going with this. I'm wondering if the goal is to understand how a pre-existing solution worked or how that same approach might be implemented in a Store-based development environment. If the former then just find an ENVY-based environment and give it a try. It had overrided without appearing as a change (in answer to your question) but was recognized as a difference by some of the ENVY code reporting tools.

 

The problems you mention were not problems for the code in the environment it was written to work in. I have not attempted to port the code to a Store-based image; therefore, I could only speculate on how it would need to be implemented. The ENVY version showed and maintained the correct code at all times. I don't doubt that a port to a Store-enabled image would need variances because there are fundamental changes in how methods relate to repostory code. It isn't that it can't be done but just that it would be done differently. VW already comes with good enough override support anyway.

 

Paul Baumann 

 

 

---

From: Terry Raymond [mailto:[hidden email]]
Sent: Thursday, November 20, 2008 1:04 PM
To: Paul Baumann; [hidden email]
Subject: RE: [vwnc] Store extensions
Importance: High

Paul

 

The problem is that if you modify the overriden method so it refers to

the renamed ivar then you have also modified the source. Now its

source is not the original source. When someone wants to view the

overriden method source what will they see? How would it compare

to its published version?

 

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

---

From: Paul Baumann [mailto:[hidden email]]
Sent: Thursday, November 20, 2008 10:03 AM
To: 'Terry Raymond'; [hidden email]
Subject: RE: [vwnc] Store extensions

 

Terry,

 

The overridden method is part of the same framework that defines the renamed inst var. It would not be inconsistent. That scenario would not happen.

 

Perhaps you meant to ask about an #override_ method referring to a renamed variable. In that case, the #override_method is rebound just like any other method. If the #override_ method refers to a variable that no longer exists then VW would notify you of a compile error at load time.

 

Here is an example of how declaring #override_ methods that reference #overridden_ methods would avoid the schema change issues:

 

    Original:

        schema: (name address)

        name

            ^name

    Original after override loaded:

        name    (copy of #override_name)

            ^self title, ' ', self overridden_name

        overridden_name  (the original #name)

            ^name

        override_name

            ^self title, ' ', self overridden_name

 

    New

        schema: (nombre address)

        name

            ^nombre

    New after override loaded:

        name    (copy of #override_name)

            ^self title, ' ', self overridden_name

        overridden_name  (the original #name)

            ^nombre

        override_name

            ^self title, ' ', self overridden_name

 

Note that if #name does not exist in the New version then the best thing to do would be to copy #override_name to #name anyway. Execution would correctly error with MNU #overridden_name if #name were sent.

 

Paul Baumann 

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond
Sent: Wednesday, November 19, 2008 2:23 PM
To: [hidden email]
Subject: Re: [vwnc] Store extensions

Paul

 

And what happens if the overridden method refers to a renamed

instance variable?

 

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Baumann
Sent: Wednesday, November 19, 2008 1:35 PM
To: 'Mark Plas'; Dennis Smith
Cc: [hidden email]
Subject: Re: [vwnc] Store extensions

 

The pseudo variable approach is interesting, but my experience is that it is easy to transiently exchange methods.

 

I implemented method override support for both VA and VW before it became a feature of VW. The way I did it preserves the original overridden method and allows it to be seen and executed. Overrides were explicitly declared rather than accidental.

 

Application code declares a new method named #override_myMethod to override a method named #myMethod. The framework recognizes the pattern #override_* and knows to rename a method equal to the the suffex (#myMethod) to #overridden_myMethod. The framework also transiently exchanges #myMethod in the method dictionary with #override_myMethod.

 

The overridden behavior can be explicitly called from within the override method. It worked well and changes were maintained properly through loads and such. Alas, the code is only available for ENVY-based images. I sure miss being able to execute overridden code with the current VW override support. Without the ability to refer to overridden code then you need to copy (and maintain) code that may change by others in the their next release.

 

The code is available as Public Domain here:

 

http://sourceforge.net/projects/methodoverride/

 

Paul Baumann 

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark Plas
Sent: Wednesday, November 19, 2008 10:44 AM
To: Dennis Smith
Cc: [hidden email]
Subject: Re: [vwnc] Store extensions

Dennis,

 

“On the note of extending methods, one could do that
by making the overridden method available to be invoked
by the new method.”

 

Perhaps a pseudo variable ‘overriddenMethod’ can be introduced (like #thisContext) and that responds to #value, #value:, #value:value: etc. Then you can write:

 

myOverriddenMethod: aString

 

      self firstDoSomethingDifferent.

      overriddenMethod value: aString.

      self doSomeOtherThings

 

That sounds interesting.

 

This technique can make the customisation of the development environment easier. For instance, instead of having to override a method to add a single new menu item (and losing menuitems in future updates), you could override it by doing:

 

menu

 

      ^overriddenMethod value addItem: <…item…>

 

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dennis Smith
Sent: woensdag 19 november 2008 16:03
To: Stefan Schmiedl
Cc: [hidden email]
Subject: Re: [vwnc] Store extensions

 

Well I can see two (in different cases).

Some classes are referred to by name, particularly in
the UI subsystems, so to use a subclass you still have
to go and make a change to at least one other class.

Also, in the case of something like "Object", you cannot
subclass it to get what you want.

On the note of extending methods, one could do that
by making the overridden method available to be invoked
by the new method.

Stefan Schmiedl wrote:

On Wed, 19 Nov 2008 14:34:02 +0100

Mark Plas [hidden email] wrote:

Any thoughts on this?

What's the advantage over creating a subclass and refering

to the superclass implementation?

s.

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 

-- 

Dennis Smith                                   +1 416.798.7948

Cherniak Software Development Corporation   Fax: +1 416.798.0948

509-2001 Sheppard Avenue East        [hidden email]

Toronto, ON M2J 4Z8              <a
href="sip:dennis@CherniakSoftware.com">sip:dennis@...

Canada                          http://www.CherniakSoftware.com

Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

 

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

 

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

 

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

All:

Thought I would just pop in here and chat up some things.

First, "Overrides" aren't per se a Store thing, but rather a Code  
Management thing. You can do overrides without Store being loaded.  
That said, it is a meaningless quibble, since we have recently  
expanded the charted of "Store" to include Code Management, so I'm on  
the hook for these things anyway.

If I had my druthers, I wouldn't allow Class overrides! (Nor Namespace  
or Shared overrides).

Oh, I know, heresy... Particularly in the "It's Smalltalk, I Should Be  
Able To Do Anything" world we live in.

But they aren't really needed!

For instance, what gain do you have for overriding a Shared? To change  
its initializer? Silly! (I said I was being heretical!) (make the  
change in a new #initialize method for the class or something!)

How about a Namespace? To change its imports? More Silly! (create your  
own new sub-namespace and add imports to that!)

Finally, for Classes... First off, I'd outlaw overriding to RENAME an  
instance variable. Mega Silly!

Adding instance variables? OY. There is a SIMPLE pattern that you can  
use to overcome that need:

1) Add your own Shared to the class... Call it MyInstanceVariables if  
you want.
2) Have this new Shared initialize to a Dictionary.
3) For every "Instance Variable" you want to add, just write the  
following:

myVariable1

        MyInstanceVariables at: #myVariable1 ifAbsentPut: [IdentityDictionary  
new].
        ^(MyInstanceVariables at: #myVariable1) at: self ifAbsent: [nil]


myVariable1: anObject

        MyInstanceVariables at: #myVariable1 ifAbsentPut: [IdentityDictionary  
new].
        (MyInstanceVariables at: #myVariable) at: self put: anObject

Now, if you don't like these things hanging around, you can add:

release
       
        (MyInstanceVariables at: #myVariable) at: self ifAbsent: [^self].
        (MyInstanceVariables at: #myVariable) at: self put: nil.
         "or"
        (MyInstanceVariables at: #myVariable) removeKey: self.

If you wanted a classInstance variable... Well, wherever the above  
reads "self" change it to "self class"

Now, you can get fancy by doing access protection and all that, or  
maybe generalize the whole thing into some kind of getMyVar and  
putMyVar: methods. But the bottom line is, you do not have to override  
classes to add variables. We just make it simple to do so.

FWIW, here is something else you CAN do with a class override, which I  
hope we will soon disallow:

You can create Class Override and change its superclass!

SILLY TO THE N-TH DEGREE!

I'd still keep around Method Overrides. Those are great.

Finally, to make sure EVERYONE understands, except for the ability to  
change the superclass on an override, we don't plan to change/get rid  
of ANY of these capabilities... Just saying: Silly is Silly.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

You weren't serious about that pattern to add variables, were you?

Cheers!

-Boris (via BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: Terry Raymond <[hidden email]>
Cc: [hidden email] <[hidden email]>
Sent: Fri Nov 21 15:32:55 2008
Subject: Re: [vwnc] Store extensions

All:

Thought I would just pop in here and chat up some things.

First, "Overrides" aren't per se a Store thing, but rather a Code 
Management thing. You can do overrides without Store being loaded. 
That said, it is a meaningless quibble, since we have recently 
expanded the charted of "Store" to include Code Management, so I'm on 
the hook for these things anyway.

If I had my druthers, I wouldn't allow Class overrides! (Nor Namespace 
or Shared overrides).

Oh, I know, heresy... Particularly in the "It's Smalltalk, I Should Be 
Able To Do Anything" world we live in.

But they aren't really needed!

For instance, what gain do you have for overriding a Shared? To change 
its initializer? Silly! (I said I was being heretical!) (make the 
change in a new #initialize method for the class or something!)

How about a Namespace? To change its imports? More Silly! (create your 
own new sub-namespace and add imports to that!)

Finally, for Classes... First off, I'd outlaw overriding to RENAME an 
instance variable. Mega Silly!

Adding instance variables? OY. There is a SIMPLE pattern that you can 
use to overcome that need:

1) Add your own Shared to the class... Call it MyInstanceVariables if 
you want.
2) Have this new Shared initialize to a Dictionary.
3) For every "Instance Variable" you want to add, just write the 
following:

myVariable1

        MyInstanceVariables at: #myVariable1 ifAbsentPut: [IdentityDictionary 
new].
        ^(MyInstanceVariables at: #myVariable1) at: self ifAbsent: [nil]


myVariable1: anObject

        MyInstanceVariables at: #myVariable1 ifAbsentPut: [IdentityDictionary 
new].
        (MyInstanceVariables at: #myVariable) at: self put: anObject

Now, if you don't like these things hanging around, you can add:

release
       
        (MyInstanceVariables at: #myVariable) at: self ifAbsent: [^self].
        (MyInstanceVariables at: #myVariable) at: self put: nil.
         "or"
        (MyInstanceVariables at: #myVariable) removeKey: self.

If you wanted a classInstance variable... Well, wherever the above 
reads "self" change it to "self class"

Now, you can get fancy by doing access protection and all that, or 
maybe generalize the whole thing into some kind of getMyVar and 
putMyVar: methods. But the bottom line is, you do not have to override 
classes to add variables. We just make it simple to do so.

FWIW, here is something else you CAN do with a class override, which I 
hope we will soon disallow:

You can create Class Override and change its superclass!

SILLY TO THE N-TH DEGREE!

I'd still keep around Method Overrides. Those are great.

Finally, to make sure EVERYONE understands, except for the ability to 
change the superclass on an override, we don't plan to change/get rid 
of ANY of these capabilities... Just saying: Silly is Silly.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris:

> You weren't serious about that pattern to add variables, were you?


Deadly Serious!

Why not?

Sure there are all kinds of arguments to be made about ugly, and maybe  
slow, and other things, but seriously...

It works!

Also... What would you do if there were NO overrides (or pragmas as in  
Travis' thing)? The answer IS that pattern.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Samuel S. Shuster wrote:

Boris:

  

You weren't serious about that pattern to add variables, were you?
    

Deadly Serious!

Why not?

Sure there are all kinds of arguments to be made about ugly, and maybe  
slow, and other things, but seriously...

It works!
  

Works yes -- but trust me you don't want to do that if, for example, you are working with
Gemstone where flushing/faulting a Dictionary is considerable overhead.
I suspect there are other cases too where you don't want to do that!!

Also... What would you do if there were NO overrides (or pragmas as in  
Travis' thing)? The answer IS that pattern.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Sam!

> Thought I would just pop in here and chat up some things.


I'm glad you did, what you write kinda scares me...




Our main use for overrides is managing patches we apply to the Cincom  
provided code.

As such it has to be terse and self-documenting.
This is because switching to a new VW release involves reviewing and  
understanding all the '* patches' packages in or system, this is a /
major/ task. Anything that makes it harder to perform this task is  
obviously not welcome.

So if I need to publish a fix to the initializer of some Shared  
defined by Cincom I want to publish just that. More precisely: I want  
it to show up in my 'foo patches' package as a _shared_ redeclaration,  
not as the introduction of a new #initialize _method_.






The other major use of overrides is that of managing extensions to  
third-party code.

In the case of adding an instance variable it is simply silly that an  
override is needed. IMO this dependency should be cut. Adding ivar  
declarations using pragmas/tags is a hack though in that it also  
suffers from the problem of ivars not showing up as ivar declarations  
in my package, but as method declarations.






Curving back to managing patches to Cincom code: it seems to me that  
Paul's suggestion for method override implementation could give us a  
lot of benefit in that Smalllint might be able to join the game. If it  
is not to hard to implement (ahem) this could be a slam-dunk product  
enhancement.






So errr, how can I nudge you to take a different view on this all?

When you write

> myVariable1 MyInstanceVariables at: #myVariable1 ifAbsentPut:  
> [IdentityDictionary new]. ^(MyInstanceVariables at: #myVariable1)  
> at: self ifAbsent: [nil] myVariable1: anObject MyInstanceVariables  
> at: #myVariable1 ifAbsentPut: [IdentityDictionary new].  
> (MyInstanceVariables at: #myVariable) at: self put: anObject release  
> (MyInstanceVariables at: #myVariable) at: self ifAbsent: [^self].  
> (MyInstanceVariables at: #myVariable) at: self put: nil.  
> "or" (MyInstanceVariables at: #myVariable) removeKey: self.


I cringe because I feel like I am stating the obvious when I say that  
is a lot of noise for declaring an ivar extension and that it is your  
quest to shield us poor programmers from this kind of stuff. We are in  
flow at a different level of abstraction and don't want to be disturbed.

Similarly

> FWIW, here is something else you CAN do with a class override, which I
> hope we will soon disallow:
>
> You can create Class Override and change its superclass!


makes my spine tingle, because it seems you are shifting the framework  
from providing mechanism to providing protocol.
I don't understand why, and the way you present it suggests it is to  
make your quest easier. But what horrible hack will I need when I'm in  
a situation where I do need to change the superclass of some third-
party class. How will introducing such limitation of expression affect  
the readability/maintainability of my source code, it seems that is  
getting worse instead of better.



In short please take your eye of the 'SILLY' meter. Over here we know  
that it is stuck at 130% in the case of overrides, no need to actually  
look.

Constructing a 'merit' meter is a bit harder of course, but I guess it  
would measure how well the system is able to support us in managing  
code declarations at the right level of abstraction, how well it fits  
into the software development process and not so much at how silly its  
implementation is.



Cheers :-)

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi all,

I would like to get soem input regarding the working of self signed
certificates in vw7.6.

I am in the middle of a development where i  need to communicate with a host
using XML over HTTPS.

I used IE7 to export the certificate associated with the host, but it was
already expired. But i was replied for my mail, by the host, that the
certificate is self signed (because it is not the live/production server)
and i can ignore the warning message.

I tried to proceed with the exceptions but finaly fails to get the reponse
from the host( first i get Security.X509.ExtensionShouldBeCritical and then
Security.X509.SSLBadCertificate)

So i assume that i must get the valid certificate from the host to  complete
the communication. What do you think?

Simon

----- Original Message -----
From: "Reinout Heeck" <[hidden email]>
To: "vwnc-list list" <[hidden email]>
Sent: Sunday, November 23, 2008 3:40 PM
Subject: Re: [vwnc] Store extensions


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Simon Peter"<[hidden email]> wrote:
All the certificate warnings should be proceedable. Were you not able to resume the SSLBadCertificate warning ?

HTH,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I often just proceed this class of error in code I write.  It all  
depends on what type of app it is, and how serious an error this is  
for the class of app.  It can be proceeded though

James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library




On Nov 24, 2008, at 3:44 AM, Simon Peter wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Sam and others,

I have to agree with the repliers to your mail: You cannot be serious about proposing to stuff a global dictionary full with instances and their instvars?? Is the next thing to be expected from VW an instvarless smalltalk? Just one big (Weak?)(Ephemeron?)dictionary with everything in it? Hey, it could work...

When I started this thread I wanted to see whether people would be interested in some more (supported) ways of improving the current overrides. It seems there is interest. Adding an instvar to a class via an extension is long wanted and would be very useful. And being able to call an overridden method, in a nice, supported-by-cincom manner, would be great.

Today you can hardly load any dev tool/third party package into a clean image without overrides showing up. VW is promoted to have everything modifiable, and sure, you can modify everything, but there are better ways than what is available now. You also need to take into account maintainability and code versioning issues.

Instead of suggesting 'silly' (in your parlance) alternatives, it would be better to think about doing it the right way. It would definitely make VW a better product showing a good way of how to build tools on top of each other and who knows, attracting potential customers. And even if it doesn't attract new ones, it could keep the current ones happy.

The least that's needed is:

- instvars as extensions (which of course behave the same way as ordinary instvars. Ie, recompile methods when the vars change, show up in inspectors, debuggers, smallLint support)
- calling overridden methods from the override with the possibility to stack overrides. (When package1 extends #initialize, it should still be possible for package2 to extend #initialize on top of package1.)
- class inst vars in extensions

And of course keep the current way of doing overrides for those cases where the above doesn't help.

Mark

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Reinout Heeck
Sent: zondag 23 november 2008 11:11
To: vwnc-list list
Subject: Re: [vwnc] Store extensions


Hi Sam!

> Thought I would just pop in here and chat up some things.


I'm glad you did, what you write kinda scares me...




Our main use for overrides is managing patches we apply to the Cincom
provided code.

As such it has to be terse and self-documenting.
This is because switching to a new VW release involves reviewing and
understanding all the '* patches' packages in or system, this is a /
major/ task. Anything that makes it harder to perform this task is
obviously not welcome.

So if I need to publish a fix to the initializer of some Shared
defined by Cincom I want to publish just that. More precisely: I want
it to show up in my 'foo patches' package as a _shared_ redeclaration,
not as the introduction of a new #initialize _method_.






The other major use of overrides is that of managing extensions to
third-party code.

In the case of adding an instance variable it is simply silly that an
override is needed. IMO this dependency should be cut. Adding ivar
declarations using pragmas/tags is a hack though in that it also
suffers from the problem of ivars not showing up as ivar declarations
in my package, but as method declarations.






Curving back to managing patches to Cincom code: it seems to me that
Paul's suggestion for method override implementation could give us a
lot of benefit in that Smalllint might be able to join the game. If it
is not to hard to implement (ahem) this could be a slam-dunk product
enhancement.






So errr, how can I nudge you to take a different view on this all?

When you write

> myVariable1 MyInstanceVariables at: #myVariable1 ifAbsentPut:
> [IdentityDictionary new]. ^(MyInstanceVariables at: #myVariable1)
> at: self ifAbsent: [nil] myVariable1: anObject MyInstanceVariables
> at: #myVariable1 ifAbsentPut: [IdentityDictionary new].
> (MyInstanceVariables at: #myVariable) at: self put: anObject release
> (MyInstanceVariables at: #myVariable) at: self ifAbsent: [^self].
> (MyInstanceVariables at: #myVariable) at: self put: nil.
> "or" (MyInstanceVariables at: #myVariable) removeKey: self.


I cringe because I feel like I am stating the obvious when I say that
is a lot of noise for declaring an ivar extension and that it is your
quest to shield us poor programmers from this kind of stuff. We are in
flow at a different level of abstraction and don't want to be disturbed.

Similarly

> FWIW, here is something else you CAN do with a class override, which I
> hope we will soon disallow:
>
> You can create Class Override and change its superclass!


makes my spine tingle, because it seems you are shifting the framework
from providing mechanism to providing protocol.
I don't understand why, and the way you present it suggests it is to
make your quest easier. But what horrible hack will I need when I'm in
a situation where I do need to change the superclass of some third-
party class. How will introducing such limitation of expression affect
the readability/maintainability of my source code, it seems that is
getting worse instead of better.



In short please take your eye of the 'SILLY' meter. Over here we know
that it is stuck at 130% in the case of overrides, no need to actually
look.

Constructing a 'merit' meter is a bit harder of course, but I guess it
would measure how well the system is able to support us in managing
code declarations at the right level of abstraction, how well it fits
into the software development process and not so much at how silly its
implementation is.



Cheers :-)

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mark:

>  Is the next thing to be expected from VW an instvarless smalltalk?


Absolutely not. If you want that, use Newspeak or Self or some slot  
based language.

My simple (but seemingly poorly ironic-ized) point was that there are  
alternatives that exist for two classes of class overrides (iVar and  
classInstanceIvar) that don't cause the problems noted.

Finally note: I don't have a dog in this hunt. And outside of managing  
how they are saved/loaded, I am not involved in that area of the  
product: The language.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Adding an inst var rather than having to override the entire class definition would definitely be useful, although I can't say that it's high on our current priority list. Implementing CLOS method combinators on overrides seems a bit of overkill to me.

At 11:30 AM 11/25/2008, Mark Plas wrote:

Hi Sam and others,

I have to agree with the repliers to your mail: You cannot be serious about proposing to stuff a global dictionary full with instances and their instvars?? Is the next thing to be expected from VW an instvarless smalltalk? Just one big (Weak?)(Ephemeron?)dictionary with everything in it? Hey, it could work...

When I started this thread I wanted to see whether people would be interested in some more (supported) ways of improving the current overrides. It seems there is interest. Adding an instvar to a class via an extension is long wanted and would be very useful. And being able to call an overridden method, in a nice, supported-by-cincom manner, would be great.

Today you can hardly load any dev tool/third party package into a clean image without overrides showing up. VW is promoted to have everything modifiable, and sure, you can modify everything, but there are better ways than what is available now. You also need to take into account maintainability and code versioning issues.

Instead of suggesting 'silly' (in your parlance) alternatives, it would be better to think about doing it the right way. It would definitely make VW a better product showing a good way of how to build tools on top of each other and who knows, attracting potential customers. And even if it doesn't attract new ones, it could keep the current ones happy.

The least that's needed is:

- instvars as extensions (which of course behave the same way as ordinary instvars. Ie, recompile methods when the vars change, show up in inspectors, debuggers, smallLint support)
- calling overridden methods from the override with the possibility to stack overrides. (When package1 extends #initialize, it should still be possible for package2 to extend #initialize on top of package1.)
- class inst vars in extensions

And of course keep the current way of doing overrides for those cases where the above doesn't help.

Mark

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Reinout Heeck
Sent: zondag 23 november 2008 11:11
To: vwnc-list list
Subject: Re: [vwnc] Store extensions


Hi Sam!

> Thought I would just pop in here and chat up some things.


I'm glad you did, what you write kinda scares me...




Our main use for overrides is managing patches we apply to the Cincom
provided code.

As such it has to be terse and self-documenting.
This is because switching to a new VW release involves reviewing and
understanding all the '* patches' packages in or system, this is a /
major/ task. Anything that makes it harder to perform this task is
obviously not welcome.

So if I need to publish a fix to the initializer of some Shared
defined by Cincom I want to publish just that. More precisely: I want
it to show up in my 'foo patches' package as a _shared_ redeclaration,
not as the introduction of a new #initialize _method_.






The other major use of overrides is that of managing extensions to
third-party code.

In the case of adding an instance variable it is simply silly that an
override is needed. IMO this dependency should be cut. Adding ivar
declarations using pragmas/tags is a hack though in that it also
suffers from the problem of ivars not showing up as ivar declarations
in my package, but as method declarations.






Curving back to managing patches to Cincom code: it seems to me that
Paul's suggestion for method override implementation could give us a
lot of benefit in that Smalllint might be able to join the game. If it
is not to hard to implement (ahem) this could be a slam-dunk product
enhancement.






So errr, how can I nudge you to take a different view on this all?

When you write

> myVariable1 MyInstanceVariables at: #myVariable1 ifAbsentPut:
> [IdentityDictionary new]. ^(MyInstanceVariables at: #myVariable1)
> at: self ifAbsent: [nil] myVariable1: anObject MyInstanceVariables
> at: #myVariable1 ifAbsentPut: [IdentityDictionary new].
> (MyInstanceVariables at: #myVariable) at: self put: anObject release
> (MyInstanceVariables at: #myVariable) at: self ifAbsent: [^self].
> (MyInstanceVariables at: #myVariable) at: self put: nil.
> "or" (MyInstanceVariables at: #myVariable) removeKey: self.


I cringe because I feel like I am stating the obvious when I say that
is a lot of noise for declaring an ivar extension and that it is your
quest to shield us poor programmers from this kind of stuff. We are in
flow at a different level of abstraction and don't want to be disturbed.

Similarly

> FWIW, here is something else you CAN do with a class override, which I
> hope we will soon disallow:
>
> You can create Class Override and change its superclass!


makes my spine tingle, because it seems you are shifting the framework
from providing mechanism to providing protocol.
I don't understand why, and the way you present it suggests it is to
make your quest easier. But what horrible hack will I need when I'm in
a situation where I do need to change the superclass of some third-
party class. How will introducing such limitation of expression affect
the readability/maintainability of my source code, it seems that is
getting worse instead of better.



In short please take your eye of the 'SILLY' meter. Over here we know
that it is stuck at 130% in the case of overrides, no need to actually
look.

Constructing a 'merit' meter is a bit harder of course, but I guess it
would measure how well the system is able to support us in managing
code declarations at the right level of abstraction, how well it fits
into the software development process and not so much at how silly its
implementation is.



Cheers :-)

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

An interesting thread with an interesting set of ideas. Interesting  
enough to suck some of my vacation time doing "hobby work" and report  
my findings here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=A_Before_and_After_Story&entry=3405092082

Two random comments loosely related to things I saw go by (and did not  
cover in the blog post above):

1) I think patches on top of patches is an obsessively degenerate case  
to worry about, and a pandora's box to manage. It's straightforward to  
reason about patches as "outside code" and "my code" and "my code's  
needs always win."

2) I still rather like the idea of having real objects for instance  
variables, and for defining them methodically. It solves this problem,  
and allows other neat things to happen at the instance variables level.

--
Travis Griggs
Objologist
If you can't say "Did it First!", you'd better be able to say "Did it  
Better!"


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Samuel S. Shuster wrote:

> ...
> Adding instance variables? OY. There is a SIMPLE pattern that you can  
> use to overcome that need:
>
> 1) Add your own Shared to the class... Call it MyInstanceVariables if  
> you want.
> 2) Have this new Shared initialize to a Dictionary.
> 3) For every "Instance Variable" you want to add, just write the  
> following...

What happens when you use reflection to try and do things with the
instVars on a class that has been extended that way? The regular
reflective techniques wouldn't know about the Shared.

As we all know reflection can be very useful. Wouldn't this technique
completely break the general pattern?

cheers
Steve A
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hello Mark,
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi all,

For my application i needed to send xml requests over the secure http.
I have the X509 certificate of the format CN=*.hostserver.com.

The URL to which i send request is of the form
'https://aSpecificHost.hostserver.com/....'

So this causes a mismatch in the
Net.SSLConnection-->validationBlock ,   where it checks if the certificate
CN matches with the request's HostName

and i get an SSLBadCertificateError.

The certificate is a genuine wild card certificate used for my hosts under
the provider.

Some one have any clues regarding a fix for this?

Thanks in Advance,

Simon

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Try to use the following example - just change the code in the
SSLWarning handler to do appropriate certificate validation


client := HttpsClient new.
    request := HttpRequest post: self authorityURL.
 
    "Add connection error handling outside here"
[client executeRequest: request] on:SSLWarning do:[:ex |Transcript cr
;show:ex defaultMessageText,'-',  ex description. ex resume]

Simon Peter wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

You can also just change the validation block on http client (see
#validationBlock:) or use the following override to make it more
transparent,

Net.HttpClient>>executeRequestDo: aBlock
        | streamx |
        self protocol = 'https' ifTrue: [self validationBlock: [:dnd |
dnd CN match: self hostName]].
        streamx := self privateExecuteRequest.
        aBlock ifNotNil: [aBlock value: streamx]

Hope this helps,

-Boris

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


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Mark Pirogovsky
Sent: Wednesday, July 22, 2009 6:54 AM
To: Simon Peter
Cc: VW NC
Subject: Re: [vwnc] SSL certificates CN mismatch

Try to use the following example - just change the code in the
SSLWarning handler to do appropriate certificate validation


client := HttpsClient new.
    request := HttpRequest post: self authorityURL.
 
    "Add connection error handling outside here"
[client executeRequest: request] on:SSLWarning do:[:ex |Transcript cr
;show:ex defaultMessageText,'-',  ex description. ex resume]

Simon Peter wrote: certificate
> CN matches with the request's HostName
>
> and i get an SSLBadCertificateError.
>
> The certificate is a genuine wild card certificate used for my hosts
under
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc