> Marcus Boerger wrote:
>> In no language i know (c++, delphi, java as the popular ones) a ctor
>
> First of all I'm a bit sad that you compare PHP with 'old' static OO
> languages, not 'modern' dynamic ones like Python or Ruby. Wrong focus
> IMHO.
First of all, PHP's object model is most similar to the Java one, so
Markus' comparisons make most sense in my eyes.
Anyway, you asked for comparisons with modern, dynamic languages:
Python: "As a special constraint on constructors, no value may be
returned; doing so will cause a TypeError to be raised at runtime." [1]
Ruby: Thanks to friendly assistance in freenode's #ruby-lang, I can report
that it is possible (and simple) to override 'new' by simply defining a
'new' class method.
Smalltalk: (similar to Ruby)
Common Lisp: It is possible in CL aswell, by overriding MAKE-INSTANCE.
Anyway, notice that each of those languages have much larger dynamicity
than PHP and its object model. For instance, it's possible to redefine
methods, to alter object methods at runtime, the classes themselves are
objects, too. I.e. to repeat what I said above, comparing PHP's OO model
with Java's is much more 'on focus' than comparing it with "modern
dynamic" languages.
> Second I don't think that's a very strong point: None of the mentioned
> languages have the notion of a method __call either (not sure about
> Delphi). It's fine to copy from other languages but that doesn't mean
> that you cannot find better ways of doing things.
Alright, but there's also a certain focus or idea behind the current
object model. And not only in the object model of PHP, Java and C++, but
also in Python, Ruby, Common Lisp and Smalltalk it's most common to throw
an exception from the constructor (it's especially odd that you refer to
"modern dynamic" languages in that context, as for instance in Python
there is no error handling but by using exceptions).
>> If you ask me i am pretty fine with (otherwise i wouldn't have made it
>> so):
>> try {
>> $db = new SQLiteDatabase($file);
>> }
>> catch (Exception $e) {
>
> If this is the *only* place in my whole application where I use
> try/catch I'd rather have another way of doing it. It's much to heavy a
> construct for this single case.
Well, your point before was that it's used only about 10 times per
library. You shouldn't worry too much about 'heavy constructs', then.
>> try {
>> // some control code here: start-ob,
>> error-handler-that-throws-exceptions
>> $db = new SQLiteDatabase($file);
>> // your normal code **without a single error-handling-if**
>> }
>
> Have you ever really used exceptions? What you're proposing is nothing
> better than set_error_handler on a global level. If you use exceptions
> all over your application though you quickly make things much more
> complicated, e.g. you need a DB with transactions (goodbye MySQL),
> otherwise you will end up with inconsistent DB states. And that's just
> the tip of the iceberg. Trust me, I've been there.
Well, you handle errors in each case. Exceptions just simplify non-local
propagation of errors, so I fail to see your point.
>> It not only has to be done in your PHP script but also internally at
>> several
>> more places. So for me this is no option.
>
> If you could give me back a null pointer that wouldn't be a problem.
> Otherwise you need one bit per object stating if it is valid. And one
> line per user-visible method. I don't think that's asked too much.
> You're writing this code once but it will be used thousands of times.
Yeah. And well, people should be able to rely on the idea of 'new' not
returning NULL (at least in the common cases, i.e. in the design of the
'standard library'), I think. Not even C++ does return 0 from 'new' (by
default :).
>> Me too, i use both where appropriate.
>
> Same here with the difference that I still haven't found where
> exceptions are appropriate yet (-:C
This is interesting. Do you have any explanations of the apparent failure
of exceptions for you, or any suggestions on how to improve them (like, by
making them resumable as in CL, or by generalizing them into first-class
continuations)?
Cheers,
Michael
[1] http://www.python.org/doc/current/ref/customization.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
