about final methods and attributes

You´re right, sorry about the final attributes. I´m developing an IDL2PHP5 mapping specification and a compiler. To be full CORBA 2.3 aligned, I´m using Java IDL mapping specification as a base for the PHP IDL specification. CORBA Enums can be mapped as constants (like Universe extension) or classes (like Java specification). Since PHP5 offers type hinting, type safe will be done at engine level with classes. So the mapping would be something like this: // generated PHP final class <enum_name> implements org__omg__CORBA__portable__IDLEntity { // one pair for each label in the enum const mapping = array ( "<label>"=><value>, ... "<label>"=><value>); // one static declaration for each label in the enum static public $<label> = null; private $value; static public function initialize() { foreach (<enum_name>::mapping as $name=>$value) { eval("<enum_name>::\$$name = new <enum_name>(\$value);"); } } private function __construct($value) { $this->value = $value; } // get the enum value public function value() { return $this->value; } // get enum with specified value static public function from_int($value) {...} static public function readResolve() {...} } <enum_name>::initialize(); The org__omg__CORBA__* stuff is needed because namespaces are now R.I.P. and my first implementation was done with namespaces (god damn! I had to write all the specification again!). In fact, the "static public $<label> = null;" should be "const public $<label> = new Car(<value>);" but PHP5 doesn't support constant objects, so I need a mapping array and I have to initialize the static attributes at "<enum_name>::initialize();". :-( This implementation is not safe because the static objects can be modified (They should be constants or read-only). The class should be final since it must not be extended by children, assuring that its behaviour would not be modified. This is necessary since this class is in fact a list of predefined constants (in the IDL agreement) and if it gets modified at runtime this could lead to undesired results. Cristiano Duarte. "Alan Knowles" <alan@akbkhome.com> escreveu na mensagem news:3EF3A72E.8040906@akbkhome.com...

Thanx Marcus, it works great ! Cristiano Duarte "Marcus BöRger" <marcus.boerger@t-online.de> escreveu na mensagem news:173915641.20030621210803@post.rwth-aachen.de...

classes ?

by

back. But

helpfull and

very good

make it

Thanx Andi, it would help me with the consistency of the CORBA mapping. Cristiano Duarte "Andi Gutmans" <andi@zend.com> escreveu na mensagem news:5.1.0.14.2.20030622001741.02ba0180@127.0.0.1... To be quite honest, I don't see a need for final classes. Talking from my experience, classes which are designed to be final, often end up being inherited from at some point or another. This happened to me quite often in C++ when taking other people's/company's code and required fixing their source code. However, if you guys think it will help you I don't really mind adding it. At least for consistency sake even though I think it's useless :) So as far as I'm concerned you can go ahead and commit it. But I still think it's better not to use it in the long run :P Andi At 09:08 PM 6/21/2003 +0200, Marcus Börger wrote:

classes ?

by

Andi Gutmans wrote:

Consistency is the key issue here, IMHO. A typical use case for final classes and PHP might be, at some point, that a software vendor distributed his PHP application in encoded bytecode format and wants to ensure that (security) critical classes cannot change their behaviour through overriding, etc.

At 11:27 AM 6/22/2003 +0200, Sebastian Bergmann wrote:

Yeah but you can just create a remove_final($class_name) function :) Anyway, I think the real reason for final is that it allows the Java compiler to do good optimizations (i.e. get rid of virtual calls in many cases). Andi