On Fri, 26 Nov 2010, Max Vlasov wrote:

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?

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

Michael.
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to