Transient leaks

[ConvertFromOldNGs]

by allistar >> Wed, 29 Jun 2005 13:42:56 GMT

I agree with the best practices, though it's difficult with old systems created/modified by many different developers of varying skill and discipline over a long period of time, and that it can be very hard to track down transient leaks.

I can see the arguments for and against AGC (there was a time when I couldn't see any arguments against)... At some point Jade must have decided not to implement it, I'd be interested to hear their rationale

As far as a feature wishlist, mine would go something like this:

Threading (already on roadmap)

Yes, this will be good. Multithreading (of one process) is not overly practical to be used all over the place, as well as the licensing issue of chewing up another CP.

Interfaces (already on roadmap)

I can see use for this in a few clients' applications I have been involved with.

Static methods (already on roadmap)
Web Services without IIS (already on roadmap)
Load Balancing (already on roadmap)

By load balancing do you mean the TCP/IP worker farm? Ofr do you mean the load balancing of thin clients across application servers? If the latter you can already do this using the "Connection manager for JADE" software. Takea look at http://www.silvermoon.co.nz/jcm.html

Enumerations

I must be missing something with this - why would you prefer enumerations over simple class constants?

Overloading
Method pre/postconditions

The IPC, versioning, reorg and cache improvements on the roadmap look good

Indeed, I'm looking forward to the 6.1 release.

John Munro

Regards,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by John Munro >> Wed, 29 Jun 2005 14:05:38 GMT

By load balancing do you mean the TCP/IP worker farm? Ofr do you mean the load balancing of thin clients across application servers? If the latter you can already do this using the "Connection manager for JADE" software. Takea look at http://www.silvermoon.co.nz/jcm.html

Load balancing thin clients accross app servers. I know about your connection manager, and I believe you helped me write mine but it's just neater to have that built into Jade. As I have a workaround, this wouldn't have been at the top of my wishlist, but it is on there

Enumerations

I must be missing something with this - why would you prefer enumerations over simple class constants?

Let's say on a Class you have an Integer property, lockMode, which can be one of three different values. By liming access to accessor methods or using a virtual property you can ensure that callers only use one of the allowed values, but it just seems like something the language should be doing rather than the developer. Also the intellisense in the IDE would be able to give you a short list of the allowable values. Again, not on the top of the list but it'd be nice.


John Munro

FileVision UK Ltd.
Atlantic House
Imperial Way
Reading
RG2 0TD

Telephone: +44 (0) 118 903 6066
Fax: +44 (0) 118 903 6100
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact FileVision UK Ltd. immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. FileVision UK Ltd. cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform FileVision UK Ltd.

[ConvertFromOldNGs]

by allistar >> Thu, 30 Jun 2005 3:21:50 GMT

John Munro (JADE Feature Discussion) wrote:

By load balancing do you mean the TCP/IP worker farm? Ofr do you mean the load balancing of thin clients across application servers? If the latter you can already do this using the "Connection manager for JADE" software. Takea look at http://www.silvermoon.co.nz/jcm.html

Load balancing thin clients accross app servers. I know about your connection manager, and I believe you helped me write mine but it's just neater to have that built into Jade. As I have a workaround, this wouldn't have been at the top of my wishlist, but it is on there

Enumerations

I must be missing something with this - why would you prefer enumerations over simple class constants?

Let's say on a Class you have an Integer property, lockMode, which can
be one of three different values. By liming access to accessor methods or using a virtual property you can ensure that callers only use one of the allowed values, but it just seems like something the language should be doing rather than the developer. Also the intellisense in the IDE would be able to give you a short list of the allowable values. Again, not on the top of the list but it'd be nice.

In a similar vein it would be good to be able to "subclass" primitive types. We use 14:4 Decimals all over the place. It would be good to define a new type called "MoneyDecimal" defined as 14:2. Then one change to the type affects all places that use it.

Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by John Munro >> Thu, 30 Jun 2005 8:27:23 GMT

In a similar vein it would be good to be able to "subclass" primitive types. We use 14:4 Decimals all over the place. It would be good to define a new type called "MoneyDecimal" defined as 14:2. Then one change to the type affects all places that use it.

Or create new ones like Rect


John Munro

FileVision UK Ltd.
Atlantic House
Imperial Way
Reading
RG2 0TD

Telephone: +44 (0) 118 903 6066
Fax: +44 (0) 118 903 6100
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact FileVision UK Ltd. immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. FileVision UK Ltd. cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform FileVision UK Ltd.

[ConvertFromOldNGs]

by Craig >> Wed, 29 Jun 2005 23:17:49 GMT

Robert

Yes, AGC would be fantastic but then there are a whole lot of other features which are missing that would be fantastic to have too.

The fact that the two modern mainstream environments (Java and .NET) have AGC would to me indicate that it's a fairly useful feature. But, implementing it is hard and I'm not confident that Jade would get it right. Especially since, as it has been pointed out, there are "backdoor" ways to get at instances other than having references to them. To change this would break too many systems. As always, you get to a point where the design decisions made in the past hamper the future.

Regarding AGC, I've found it possible to implement a "poor-mans" GC - though not fully automatic. In one of the systems I'm maintaining, I've simply added a collection to a base form that I can add transient objects to. When the form is deleted, it loops through the collection and deletes any valid transient instances. At least then I can freely create transients and know that they'll eventually be deleted. Not a complete solution by any means, but useful to consider.

As for other features, I think that method (not operator) overloading and parameterised constructors should be high priority items. Oh, and Interfaces would be great (yes, I know they're on the roadmap).

[ConvertFromOldNGs]

by Craig >> Wed, 29 Jun 2005 23:20:13 GMT

Robert

Yes, AGC would be fantastic but then there are a whole lot of other features which are missing that would be fantastic to have too.

The fact that the two modern mainstream environments (Java and .NET) have AGC would to me indicate that it's a fairly useful feature. But, implementing it is hard and I'm not confident that Jade would get it right. Especially since, as it has been pointed out, there are "backdoor" ways to get at instances other than having references to them. To change this would break too many systems. As always, you get to a point where the design decisions made in the past hamper the future.

Regarding AGC, I've found it possible to implement a "poor-mans" GC - though not fully automatic. In one of the systems I'm maintaining, I've simply added a collection to a base form that I can add transient objects to. When the form is deleted, it loops through the collection and deletes any valid transient instances. At least then I can freely create transients and know that they'll eventually be deleted. Not a complete solution by any means, but useful to consider.

As for other features, I think that method (not operator) overloading and parameterised constructors should be high priority items. Oh, and Interfaces would be great (yes, I know they're on the roadmap).

[ConvertFromOldNGs]

by Alan >> Thu, 30 Jun 2005 6:59:47 GMT

One way of implement AGC could be via an extension to the create method - would only be applicable to transients so could use, say:
create lObject as lClass methodTransient;
It "should" be relatively simple for the system to determine which method the lObject was created in at the time it was created. Method transient objects would be cleaned up when the method terminates.
Similarly a new "createIterator" method, eg "createMethodIterator" would allow the system to do a similar thing with iterators.

[ConvertFromOldNGs]

by Torrie >> Thu, 30 Jun 2005 8:09:53 GMT

I agree about the methodTransient extension. Another feature what would make it easier to clean up would be the ability to have singleton references as exclusive references. When the owner is created it would create all the exclusive references and delete them when the owner was deleted. I know you can code this in the create and delete method but it would be nice if you didn't have to.

[ConvertFromOldNGs]

by Robert >> Sun, 3 Jul 2005 21:59:37 GMT

So "methodTransient" essentially extends the "lifetime" modifier of the create statement:

create object <as class> persistent | sharedTransient | transient | methodTransient

"methodTransient" would become the norm for process transient data, with "transient" being used only under exceptional circumstances.

This suggestion appears to provide a language-consistent solution that would make developers' lives easier (no need to remember those epilog deletes), *and* Jade marketing can tick the AGC checkbox.

The cloneSelf(), copySelf() and createIterator() methods would all benefit from similar extensions.

[ConvertFromOldNGs]

by Brendan >> Mon, 4 Jul 2005 9:46:48 GMT

While I agree that there are some merits with the methodTransient extension, I wouldn't go so far as to claim that it provides a tick in the box for AGC (though this would not stop a typical marketeer ticking furiously). Also, there are a couple of other points which can be made

1. A "proper" AGC would be automatically backward compatible (since it is a transparent solution). Existing code which didn't clean up transients properly would be magically fixed without change. The proposed solution would still require all existing code to be fixed.

2. The onus is still on the programmer to ensure methodTransient is specified. If a class has default persistence set to transient, it would be easy enough to forget to specify methodTransient on create. The debate is then is it easier to forget methodTransient than to forget delete xxx in the epilog. I am so much in the habit of coding a delete in the epilog immediately after writing a create xxx transient in the method code that I sometimes catch myself doing it quite unnecessarily in JadeScripts etc.

There are a few other points to consider:

3. If a methodTransient is assigned to a property of the self class (create xxx methodTransient, where xxx is a property) is the property automatically set to null when the method is exited? If so, this creates complications potentially along the same lines as AGC.

4. In Jade 6 process transients are never visible outside the creating process, unlike Jade 3, 4 and 5. It may well be that, because of this, AGC for process transients will be (much?) easier to implement than the "old" days when the idea was first kicked around and given a very low priority. Also, the internet was less popular so high availability was not such a high priority as it is now. In other words the parameters have changed so AGC as a feature should be reviewed by the plant.

I would say that, because of the above, I would favour a full-blown AGC for process transients, rather than the methodTransient extension. To avoid breaking existing systems, this should be controlled via an ini file option.

I agree with Robert's point at the very beginning of the thread viz. that if Jade's mission is to make programming easier, JADE should support AGC. The plant has done a brilliant job applying this philosophy with cache coherency. This is transparent so gets retrofitted to existing systems with no programming. This should be the goal of AGC, if it is ever implemented.

Brendan