defined buffers vs. dynamic buffers

Why should the first one be bad? It's scoped to the method - so it's only available during the execution of the method. Regardless of the accessibility of the method.

I never would recommend to use dynamic buffers when the tablename is know already at compile time. That typically requires much more testing and changes to the DB only bang at runtime, not much more helpfully at compile time.

the first one is bad because the method is always present in memory,

as it can't be unloaded. If you execute that method, then drop back to

the editor, and try to change the data dictionary your session will

restart because of a schema change.

I don't change the dictionary that often. But I'm glad to have compile time validation of the data access every single day.

For me a key strength of the language!

Don't get me wrong - I agree with you 100% about defined buffers and dynamic buffers. That's why I generate code automatically Removes the need for dynamic buffers.

It's just that I don't like the idea of buffers hanging around in memory that you can't get rid off.

It .... just .... seems .... wrong

I also can't provide any use case where it is a problem.

It .... just .... seems .... wrong

The only thing that seems wrong to me is that you cannot get rid of static classes in your session.

But hey, that is just sometimes unconvenient in the development environment, but the goal is the production environment.

We developers can cope with it.

It's just that I don't like the idea of buffers hanging around in memory that you can't get rid off.

But the cause is not that much the buffer scope - it's because the method is static and nobody let's you unload the static 'instance' from memory.

For as much as I love the simplicity of a static API - this is would be one of the cases where a singleton approach has the advantage of being unloadable.

We developers can cope with it.

Absolutely - especially in OpenEdge Architect where the tools AVM and the developers test AVM are usually separated from each other.

or just a 'fake' singleton...

class foo():
  def private var _self as foo no-undo.
  constructor static foo ():
    _self = new foo().
  end constructor.
  method private _foo():
     def buffer xx for someTable.
     ...
  end method.
  method public static foo ():
    _self:_foo().
  end method.
end class.

I am not 100% sure (no AVM on the iPhone), but I assume the static interface and the non static implementation will need to be separate classes (different R-Code) because the DB-REFERENCES of the R-Code is recorded for the whole thing only, not separately for the static and the instance members.

indeed

My first inclination is to question the use of DB references in static classes....

this I like

you are right. Just tried this, had a schema change restart on both scenarios

Not entirely static classes, but static methods ..

I *don't* like typing

(new demo.foo()):Bar().

this is so much cleaner and easier to read.

demo.foo:Bar()

And, although you don't think that this is an issue, but the () around the (new demo.foo()) buggers up the intellisense so you don't get to see no methods, properties or events on the object.

You can, as always, do

def var foo1 as demo.foo no-undo.

foo1 = new demo.foo().

foo1:Bar().

70 chars vs 14.

3 lines vs 1

and much less readable.

you are right. Just tried this, had a schema change restart on both scenarios

Don't blame the messenger

But you can still use a static façade and behind that a singleton instance in two different classes. And use a service container approach to reference the singleton instance (rather than the static Instance property).

Not entirely static classes, but static methods ..

Being static is like being pregnant. It's all or nothing. There is no half static. A single static member makes that class what I call static.

no blame - you've actually highlighted a problem that I didn't know existed. As for the facade, changing the generator to create the two classes as we speak

Not entirely, no.  There are some special cases where it makes sense to have a static property ... or maybe a static method ... in a class which is otherwise instance attributes and I wouldn't call those static classes.  Maybe we need a word for that.  But, the more typical case of all properties and methods of a class being static, that I am happy to call a static class, even though we don't actually have static classes.

lol. I may have to make that my tag line

Thanks for the chuckle

"Being static is like being pregnant. It's all or nothing"

Following the quotes of Mike, we could call it a "phantom pregnancy" ...

and I wouldn't call those static classes.  Maybe we need a word for that. 

A new word is always a good idea.

But with regards to Julian's observation, the first static member, private or not, makes the class static enough to cause the problem.

Phantom static?

Well, isn't the problem confined to the static part?  E.g., if one defines a static property for a mutex lock or a static method for serialization or something, isn't the rest of the class going to still behave normally?  I.e., the issue is dealing with the DB in a static element.

Well, isn't the problem confined to the static part? 

No. See Julian's earlier observation.

No, as Mike mentioned earlier, because the db-references are tied to the .r of the class, if there is a static method or static property, any db reference in the class (even in a normal non-static method)  will cause the problem. You need to separate the static and normal methods into separate classes.

By "problem" do you mean simply the development time issue of having a static in memory and changing the dictionary?  Isn't that solved by not using the project AVM for the run configuration ... which I would do anyway to make sure I had a clean start?

Once the r-code for a class containing as little as one static member is loaded, it will persist for the duration of the session and you can not reload it if you change it. If it also have instance members, the data associated with each instance can be discarded, but the excution segmenst cannot. For that reason I tend to think about any class with a static member as a "persistent class". It persists for the whole session. If everything is static, the class is also static, but if some parts are instance related, I tend to refer to the static members as "class members" and the rest as "instacne members".

Thus, in my world:

1. All static classes are persistent.

2. All persistent classes are not necessarily static, but something in it is.

Now if you are still looking for a word, feel free to use "persistent" or "session persisten", as long as you kjeep to my definition.

Seems sound, although I worry a bit about possible confusion with persistent procedures.

Seems sound, although I worry a bit about possible confusion with persistent procedures.

Exactly. Especially as a persistent procedure can be unloaded.

I'd rather stick with static classes or partly statics.

In terms of the life cycle, persistent procedures are for me in essence the same as static classes, except that I can at least delete them from memmory when I know I'm done. There is nog garbage collector that will clean up after me.

The only real two differences I between a static class and a persistent procedure (that was not properly cleaned up) is that:

a) There is a way to hunt the latter down and kill it (or better yet, find out what created it and fix its cleanup).

b) You can end up with duplicate persistent procedures, while it is by nature not possible with static classes.

Important differences, I'd say.

I am not happy with static because it means something very specific and, moreover, that meaning applies to classes.  The one saving grace of the word persistent is that it is a word which does not apply to classes.

Maybe perpetual?

In my (sad) mind, I think that it really needs to made clear that

1) a "static class" exists if, and only if, all methods and properties

of that class are static.

2) a non-static class exists if, and only if, all methods and

properties of that class are not static.

Otherwise we have a hybrid class.

 * jmls likes that name.

Hybrid class. Sounds cool and green

Hybrid because it is partly static?  Not very intuitive to me and it doesn't specifically convey the issue of it sticking around.

I.e., I think we want a word which addresses the behavior of code locked in memory, something that applies both to proper static classes and to these partly static classes.  Persistent or perpetual bring that to mind.

Perhaps we also need a good term for a class which has both static and regular elements.  Hybrid might apply there, but doesn't bring the specific quality to mind.  I'm not sure that partly static isn't a sufficient and clear term.

Hybrid class. Sounds cool and green

Please, no!!! The term hybrid class is used by Progress for an ABL class that inherits from a .NET class. I see that as a conflicting term in the context of ABL classes.

I will stick to static classes. Because it describes the keyword that is responsible for this circumstance. Sorry - I see no need to artificially seek another term. For what?

 * jmls slips mike a chill pill, and withdraws the hybrid designation

 * admin slips mike a chill pill, and withdraws the hybrid designation

Mike, out of this thread...

Small update: Everybody still seeking a new term: Create a class with at least a static method and a static constructor and raise an error from the static constructor.

Static instance failed to load. Cannot reference class Consultingwerk.StaticInstance.Test. (14631)

Nachricht geändert durch Mike Fechner