Hi,

I thought about OOP recently, as many sometimes wonder that it's not as good as it can be in some areas. For example, the OOP encapsulation is good, but sometimes the developer doesn't track the context completely or makes other "bad" things related to the hidden nature of encapsulation context. The notion of name the variables with "f" at the start also speaks itself about these problems.

An idea here is to introduce a directive (maybe something else, but directive looks more straightforward), let's call it readonly that forces the method to be able only to read the fields and properties of the object it belongs to and forbid any writing. Sure in this case it only can call only the methods also containing such directive.

One of example of possible usage: TBitmap contains PixelFormat, when user changes it, there should be a conversion, but to be more sure that it will be accurate and there are no side effects I'd mark the method for conversion with this directive so it will only read existing properties and create some new one to return in variable passed by reference. With this directive on, any attempt of this method to change the fields related to bits or handle will be stopped by the compiler, also if it tries to call a read/write method, the compiler will also stops. There are others examples that come to mind, all allowing oop programming to be more controlled.

I thing there might be some logical contradictions I'm not aware at the moment, but I think they can be resolved with general oop inheritance logic.

What do you think? Is anyone aware of similar concept in any other OOP language? Apart from the idea (worth it or not), there's also a question about introducing brand-new features in fpc. Are developers (read "Florian" :) is open to introducing new features that later possible other parties (read Embarcadero :) will be willing to adapt?

Thanks,

Max Vlasov

Everything we introduced first Embarcadero has consistently done different, so I would not hope for that.

Michael.

Michael Van Canneyt wrote

Everything we introduced first Embarcadero has consistently done different, so I would not hope for that.

Exit(Value) not.

Btw, maybe to discuss new features on Embarcadero forum too before the final decision?

Best regards,
Paul Ishenin.

Paul Ishenin wrote

26.11.2010 16:38, Michael Van Canneyt wrote: > Everything we introduced first Embarcadero has consistently done different, > so I would not hope for that. Exit(Value) not.

I don't see how they could have done that different :)

Michael.

Paul, you mean encouraging them to implement this and return to this discussion when D2011(12,13..) implements this? :) Just kidding

Speaking of new features, I remember the bunch of them were introduced with Delphi 1.0 and many of them were inspired by other languages and dialects. I admit that frequent implementing of features like the one I suggested will make fpc more experimental and less solid. So consider it an idea just thrown in the wild to see whether it will survive or not :)

Max

Max Vlasov wrote

Paul, you mean encouraging them to implement this and return to this discussion when D2011(12,13..) implements this? :) Just kidding

I think we need a collaboration between the communities and developers. Copperative feature discussion can be a first step in collaboration between projects.

Best regards,
Paul Ishenin

Max Vlasov пишет:

This particular idea probably won't survive. In 'unsafe' language with pointers, there's no way to enforce the restriction you suggest. It will only cause annoyance and make people implement 'workarounds'.

Sergei

Sergei, around what code? if implemented, by default all methods read/write. If a developer restricts readonly directive to its own method, it is his own decision. For example, you're writing method Find, you understand that it hasn't change anything in the object state, you apply this directive to help yourself in the future :) if you talk about virtual readonly method someone introduced, it's similar to private section of object, you can love it or hate it, but this features exists (sure sometimes bringing real pain :) restricting usage of this method in other units.

Another example, you successfully wrote first version of a method with reaonly directive, you try to change something several months later and one of your changes is try to change a field inside method implementaion, the compiler points out to the restriction and stops. You have two options: beat yourself for this silly change or understand that the state changing is really needed. If the latter, ok, press ctrl-shift-up, and delete reaonly directive, no problem :)

Max

Also, one note to consider
It is know that some of OOP concepts can be implemented with procedural language. For example, pseudo-encapsulation with the records. Ironically, this idea can be implemented using the emulation.

Compare

procedure MyObjFind(var Rec: TMyObjData) with
procedure MyObjFind(const Rec: TMyObjData)

the latter is actual readonly emulation, you won't be able to change anything and you won't be able to pass this record by reference to any other procedure

Max Vlasov

Max Vlasov пишет:

I tend to think that the primary goal of introducing 'const' parameters was optimization, not access restriction. Although I don't know exactly.

Sergei

Max Vlasov wrote

Is anyone aware of similar concept in any other OOP language?

Yes, C++ has it:
http://duramecho.com/ComputerInformation/WhyHowCppConst.html

It's true that it's a little bit messy, but that's pretty much the norm with everything in C++ ;-)

On Fri, Nov 26, 2010 at 9:45 PM, Nikolay Nikolov <

Thanks, Nikolay, it's interesting information, when I tried to search before I posted, I didn't use "const", only "read only" so did not find anything. I already see that it never would be implemented the similar way since in contrary to C++ const objects in pascal already can do whatever they want.

Also searching now, found a post

http://community.freepascal.org:10000/bboards/message?message_id=256912&forum_id=24082

Where was question about const, but it seems that primary discussion was about optimization, not preventing from occasional modification.

Max Vlasov

That's one of the things that "const" can do in C++.

I thing there might be some logical contradictions I'm not aware at the moment, but I think they can be resolved with general oop inheritance logic.

My experience with "const" methods in C++ often resulted in a bunch of cloned methods, with only calls to other non-const methods removed - a maintenance nightmare :-(

A workaround could include the same implementation code twice, with conditional compilation of all non-const parts. But since the method names of the const and non-const versions must be different, every method body must reside in its own include file..

DoDi

Just curious, was it a "fight" with yourself or with someone else's code? Sure I had no experience with const methods, but I just can't imagine how function or procedures intended to caclulate/find/collect some information from the fields and properties of an object can be a problem in this field. One example comes to mind, sometimes developer wants to know how often a method is used, sure in this case there's no easy way to increase a feild of the object. Can you name some other examples?

Max

No, this example is not the reason to duplicate methods, since C++ has a special "mutable" modifier to get around this specific problem.

Both.

Perhaps it's not so a problem with typical OPL code. Most critical is passing along a const reference, to procedures that possibly can do more with the object. Once you hit such an call tree, many of the called procedures have to be converted (or cloned), to accept and work with strictly const references.

DoDi

No, this example is not the reason to duplicate methods, since C++ has a special "mutable" modifier to get around this specific problem.

Ah, this modifier was not yet available when I was coding C++ in the early 90s. Good to know that we'll have implement the same backdoor, in case we ever want to implement const references.

DoDi