[PHP-DEV] Re: [RFC] Stricter type-checks for arithmetic/bitwise operators
Nikita Popov wrote: I would like to propose making the use of arithmetic/bitwise operators on arrays, resources and (non-overloaded) objects a TypeError exception: https://wiki.php.net/rfc/arithmetic_operator_type_checks This is inspired by some of the recent discussions, in particular the operator overloading RFC (where the fact that operations on non-overloaded objects still succeed with just a notice was criticized) and the increment/decrement RFC, which handles the array case of this proposal for inc/dec only. I think as-is, this RFC should be completely uncontroversial. However, there is an open question on whether we want to make this slightly more strict, in order to align the semantics with the rules for weak parameter type checks for ints/floats. If we do that, then this RFC could be a stepping stone towards making "implicit" internal casts use the (weak) parameter type checking semantics more generally, which I think would be a good idea. The current explicit cast semantics we use everywhere are too forgiving for most circumstances (e.g. an array is almost always not a reasonable input where an integer is expected). I definitely support this proposal, and I'd love the "strict_operators" directive as well, but that's a different proposal, and a different discussion. The current proposal seems, in the words of the proposal, to be pretty uncontroversial: It basically corrects a bunch of WTFs in PHP's type system. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] switch expression
Larry Garfield wrote:
On Sun, Mar 29, 2020, at 4:04 PM, Ilija Tovilo wrote:
What you're proposing is a language construct for an *expression*,
which evaluates depending on internal logic to a different value.
Those are sufficiently distinct that I agree they should have distinct
keywords. Plus, the internal syntax is non-trivial to switch back and
forth between (break vs not, etc.), so it is misleading for people to
present them as two slight variants on the same thing; they're really
quite distinct, and that's OK.
My recommendation would be to just borrow Rust's keyword:
$result = match ($var) {
$expression => $expression;
$expression => $expression;
$expression => $expression;
default => $expression;
}
I would tend to side with this. The way I'd interpret this is that the provided
value is matched against the value of each expression, which also means arbitrary
comparisons may be used without additional syntax or special cases, as has
been mentioned in this thread:
$temp=get_temperature();
$phase = match(true)
{
$temp<0 => "Ice",
$temp>=0 && $temp<=100 => "Water",
$temp>100 => "Steam"
}
I also agree that we should keep this as an expression, not extending it
to be a statement as well. Keep it simple. Should we want to use it as a
statement at a later point, that would be possible to add.
I also like the exhaustive check, so that the following would give an error
(and could be found using static analysis) about not handling other values
than 1-3:
$result = match($x) // int
{
1 => ...,
2 => ...,
3 => ...
}
Having a new keyword like this opens the door to further changes that moves
it away from the way switch works, such as pattern matching and destructuring.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
Stanislav wrote: I think "as long as it is not overused" are the key words there. We have a very limited number of internal classes with operator overloading I think the whole point of leaving it to extensions was ensuring it's not overused. And now I see people arguing "well, if it's available to extensions, then it also must be available to userspace" - which is the reverse of the premise under which it was implemented in the first place. Once we open this door, there's nothing that would prevent overuse and abuse - in fact, as we see, even having this door closed leads people to think since it exists, it must be used to the maximum, addition of userspace operator overloading will surely be taken as encouragement to be as creative as possible with overloading operators and inventing all kinds of incomprehensible and inconsistent operator schemes because it looked cool at the moment. So if anybody has hope it would "not be overused" - it will be. C++ has a philosophy: "Trust the programmer." [1] While I understand that many are not amused by the overloading of ">>" and "<<" to mean input and output, the larger issue is that using such stream operators and function overloading provides an elegant and extensible way of providing reading and writing of user-defined types, usable for any stream. I know PHP is not C++, but other languages has been mentioned in this context, and another core tenet of the C++ language is that it's more important to provide useful abstractions, rather than banning anything that may be misused. Let's face it, you could make "add()" _subtract_ the numbers, or do strange things, just as well as you could do with a function overloading "+". Personally, I find it a greater gain in terms of code clarity to be able to write e.g.: $result = $a + $b * $c + $d; rather than: $result = $a->add($b->multiply($c))->add($d); Quick: Is the second one exactly identical to the first one? Yes, it is, but this one's got the associativity wrong: $result = $a->add($b)->multiply($c)->add($d); Would you catch that in code? There's a reason mathematicians have invented a set of symbols: It makes it easier to comprehend code using it, than if you only use function notation. We already know how to mentally parse expressions in terms of operator precedence, and having operator overloading follow the same rules means we can use that skill also for user-defined types. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Function and operator overloading
Hi Nikita. Thanks for your response and the links. I found the search engine you linked to working well. The reason I came to think of this issue was not as much to be able to do function overloading in general, but more from the fact that the discussion on operator overloading seemed to involve a lot of struggling trying to get it right when it comes to not preventing others from adding operator overloads for your classes, and so on, and free functions that can be overloaded provides in my opinion an elegant solution to this. The method using __call() given in the last article unfortunately doesn't work for free function overloading, since it only works for methods, and we're back to the question: Which class can or should provide an overload if you have two different types of operands? I also understand that PHP's dynamically typed system makes a difference compared to statically typed languages like C++ or Java. Given this reality, I guess the current userland operator overloading proposal may be the best we can hope for, and I for one would appreciate any kind of operator overloading to none at all. Regards, Terje Please excuse me if this has been discussed to death earlier. I've tried to search for it, but I've come up empty: https://www.php.net/results.php? q=function+overloading=en=all Yes, this has already been discussed to death. The search on php.net does not extend to the mailing list archives. You may find https://externals.io/ or https://markmail.org/search/?q=list%3Anet.php.lists.internals more useful for that purpose. https://github.com/Danack/RfcCodex/blob/master/method_overloading.md provides a very high level summary on the topic. There's very little I'm sure about when it comes to the future of PHP, but one of the things I can state with some degree of conviction is that we will never introduce type-based method overloading. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Function and operator overloading
Hi.
Please excuse me if this has been discussed to death earlier. I've tried
to search for it, but I've come up empty:
https://www.php.net/results.php?
q=function+overloading=en=all
The recent discussion on operator overloading has highlighted the
relationship between function overloading and operator overloading, and
how having support for the former may help provide the latter.
For those with experience with C++, function and operator overloading
works the same way, and the only difference is that operator overloading
is defined as a function of the form "operator+(...)", i.e. "operator"
followed by the operator itself.
I know that C++'s system for overloading is very complex (because it has
something called partial ordering of functions, and it also includes
templates/generics).
Nevertheless, I think it could be possible to implement a subset in PHP,
without all the complexity, and in this way provide a cleaner way of
implementing either kind of overloading, and avoiding the "closed set" /
library interaction issues mentioned in the other thread.
What I have in mind is to let the parameter types of a function become
part of the function name, something like this:
// Function overloads
function add(Money $a, Money $b): Money
{
...
}
function add(Matrix $a, Matrix $b): Matrix
{
...
}
// Operator overloads
function operator+(Money $a, Money $b): Money
{
...
}
function operator*(Money $a, Percentage $b); Money
{
...
}
function operator*(Matrix $a, Matrix $b): Matrix
{
...
}
Use:
$m1 = new Money(100);
$m2 = new Money(200);
$p = new Percentage(10);
$result = $m1 + $m2; // Money(300)
$result = $m1 * $p; Money(10)
I realise that including the parameter types as part of the (internal)
name of a function is a major departure from the way PHP works today.
However, if we are to grow PHP into the future, and continue to provide
clean ways of expressing things, then maybe we should re-examine such
fundamental things, where a clean interface and simplicity for the
developer is more important than implementation complexity.
Regards,
Terje
[PHP-DEV] RFC: Interest in function autoloading?
Hi guys. I've searched the archive, but I haven't found anything about this issue. I notice there exists an RFC for autoloading of functions, or more to the point, a unified autoloading system for classes, functions, constants and streams: https://wiki.php.net/rfc/function_autoloading Our systems use autoloading to great effect, letting us eliminate any require_once() to load classes. However, we also have a number of free functions, which unfortunately can't be loaded the same way and have to be explicitly loaded. These included for example functions for array operations, and various functions used in our query builder. For example, we may write code like this: $condition = ["date" => greater_than()]; These functions have no place in a class, and having to prepend a class name just to make them auto-load leads to cluttered code, and feels forced. If you want to group such things, namespaces fits the bill. Reading the RFC, it doesn't appear to have happened anything since 2015, so I'm wondering if this topic has been discussed at any time, and if so, what the outcome was? In any case, I'd also be interested to hear people's opinion on this today. I think this would be a great addition to eliminate clutter, and legitimate the use of free functions, which PHP honourably provides. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC idea: Block scoped variables with "let $x = expr"
Tyson Andre wrote: Hi internals, In PHP, variables are currently scoped to the function scope, and can't be scoped to a block scope. This makes it difficult to reason about how a variable will actually be used at a glance, especially in long functions, or top-level statement lists of a file. (or how the variable was originally intended to be used) The function scope lifetime of variables in PHP is similar to how JavaScript treated variables with `var`, before the introduction of the `let` statement in JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let Would there be any interest in adding something similar to this in PHP? I'd definitely like this, and this has also been proposed as a possible future direction in the "Variable declarations before usage" RFC: https://wiki.php.net/rfc/declare_vars For reasons of backwards compatibility and avoiding having to add new keywords, we may want to consider using "var", instead of "let". Starting with scoped variables could also evolve into requiring variables to be declared using the optional "declare(declare_vars=1)" directive from the above proposal. For me, perhaps the most interesting spin-off of adding optional variable declarations would be the possibility of using typed local variables (also suggested in the above proposal), maybe something like: declare(typed_vars=1); // In case we want opt-in var $message = "Test"; // No type declaration needed, type inferred as "string" ... $message = null; // Error $message is of type string $message = new SomeMessage(); // Error $message is of type string If we don't have an initialiser, we might specify the type explicitly (note: I'm here talking about what explicitly declaring variables may be used for in the future, I'm not proposing this now): var ?string $message; ... $message = null; // OK $message = "Test"; // OK $message = new Something(); // Error, $message is of type ?string Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Userspace operator overloading
Hi Rowan. I agree that this makes sense. However, as someone else pointed out, one problem with interfaces is that they constrain the types that may be used. We have our own Money, Percentage, PricePerMm, etc. types that we'd like to define operators for, how can you define an interface in PHP that accommodate types that are unknown to the PHP implementors? If we had support for generics, we could have defined generic interfaces, but we don't so we can't. Regards, Terje Hi Terje, I think both of your examples are compatible with the idea of grouped operators, as long as we don't constrain a type to implement all operators with the same right-hand side. ... If this operator was implemented in isolation, it would again be drifting into domain-specific language territory. (I don't personally have a problem with that, but many people vocally object to it.) However, it could easily be made part of a consistent set of arithmetic operators: On class Money: Money + Money => Money Money - Money => Money Money * int => Money Money / int => Money int * Money => Money int / Money => Error Money * Percentage => Money Money / Percentage => Money Percentage * Money => Money Percentage / Money => Error Optionally, on class Percentage: Percentage + Percentage => Percentage Percentage - Percentage => Percentage Percentage* int => Percentage Percentage / int => Percentage -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Userspace operator overloading
On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote: How many of you would prefer a interface solution for operator overloading? I wonder if the RFC voting should include the option to choose between either the magic method approach (with the syntax proposed in the current RFC version) or using interfaces. For an interface version I would suggest these interfaces: ArithmeticOperators (implements +, -, *, /), PowOperator (**), ModuloOperator (%), ConcatOperator (.) and BitwiseOperators (~, &, |, ^, <<, >>> ). +1 for magic methods. There's too many domains where only a few of the operators makes sense and groupings like ArithmeticOperators would not make sense, not at least one of the motivating examples of this proposal: Being able to write a Money class and associated functionality. Adding and subtracting money makes sense, but it makes no sense to multiply or divide them, and this is just *one* domain. Please, let's not go there and artificially limit the possibilities of future developers. For example, for me, it's quite natural to be able to write code like this: $total_discount = $total * $discount; Here, $total_discount and $total is Money, while $discount is a Percentage, so we should be able to define a method that allows you to multiply Money with Percentage, and return a Money object. Adding Money and Percentage would make no sense, but multiplying them does. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
Mike Schinkel wrote: On Feb 21, 2020, at 6:17 PM, Larry Garfield wrote: Separate visibility for internal and external access is a separate matter. (Also potentially useful, but not part of the write-once proposal at the moment.) This just hit me, so I think I will mention it. The culture on the list seems not to be one of collaboration on RFC to find solutions to improve PHP but instead waiting for someone to stick their neck out with an RFC and then see who can shoot the most holes through it. Hi Mike. I'm a newcomer to this list, but many years ago, I was more active on the Boost C++ libraries list, where they have something called "formal review" and it's not for the faint of heart. In order for a library to be accepted as a Boost library, it has to go through a rather rigorous review, where everyone and anyone are allowed to poke at it and try to "shoot holes through it". This is not in any way done to discourage library writers to come up with proposals, rather the opposite: By subjecting a proposal to such scrutiny, where - like you said - people may also propose changes to deal with those issues, the proposals become that much stronger. This is similar to how science works: When someone proposes a theory, they way it's tested to check if it's any good is to essentially do "destructive testing": Try to break it, usually done first by the originator of the theory, and later by the scientific community. Take the theory of general relativity: This is one of the most well-tested theories we have, and it has passed every test thrown at it with flying colours. This is the light in which I see the reviews/discussions on this list as well: By trying to "test" proposals even in extreme ways, we learn if they are any good or not, or if they have some fundamental weaknesses that we need to address. Better to find that out now, than after it has been accepted into the language. I also think what is important is that these discussions happen in a professional and respectful way, and if you do that, then I think there's no limit to how much you may "tear a proposal apart", again, which ultimately leads to a stronger proposal, or a revision or retraction, if we find there are some serious issues that warrant a reconsideration. Now to the subject matter: I'm in favour of simple and straight rules, and I'm wondering if we might try a little too much if we are to cater for both write-once properties and lazy loading. To take how you might do it in C++, you'd make a regular class, and then make a const instance of it: const User user(...); When the constructor runs, it sets all object properties, and upon completion, they are immutable. We don't yet have the possibility to declare const objects (although this proposal mentions it as a future RFC: https://wiki.php.net/rfc/declare_vars), but maybe we could consider going this route? Using PHP syntax, we may write: const $user = new User(...); Following the construction, the object is considered const/read-only, and you can't change its object properties. There's no need to declare each property as "readonly". What about lazy loading? Well, C++ has a solution for this, as well: If you need to be able to change properties for a const object, you can mark them "mutable". I know, this doesn't address the issue of actually preventing them to be changed after having been set once, but I thought I'd at least inspire people to think about how these things are done in other languages. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Userspace operator overloading
jan.h.boeh...@gmx.de wrote: based on the discussions here (https://externals.io/message/108300) and here (https://github.com/php/php-src/pull/5156), I have created a proper RFC for userspace operator overloading: https://wiki.php.net/rfc/userspace_operator_overloading The main differences to my original concept, is the removed __compare() method (comparison overloading is a complex topic and should be handled in a different RFC) and the possibility to signal that the operator handler does not support the given types (by typehints or returning a special value). This way, only one of both objects has to know about the other type. This should expand the use case of operator overloading compared to my old concept. What do you think about the RFC? I very much appreciate this initiative, as well as that of Patricio/Sara, and I agree with what people have said about the importance of realistic use-cases for something like this. Our company produces ads, and the price calculation is quite complex, involving the size of the ads, various discounts, etc. We're using objects for these calculations, to ensure we don't mix up units. Here are some examples: $price_per_column_mm = new PricePerColumnMm(1234); // Price = 1234 * number of columns * height in mm $height = new LengthInMm(100); $price_per_column = $price_per_column_mm->multiply($height); // Returns a PricePerColumn object $columns = new Column(4); $price = $price_per_column->multiply($columns); // Returns a Money object It gets more complicated, when we add in discounts: $discount_percentage = new Percentage(10); $end_user_price = $price->subtract($discount_percentage); // Price = Price * (100-discount percentage)/100 These are just a few examples, but it shows the advantage of using strongly typed objects in expressions, so that we don't do nonsensical things like multiplying two Money objects, or try to use a PricePerColumn object as a Money object. As you can probably tell, having all those "add", "subtract", "multiply", etc. method calls makes it hard to understand what is going on, and even if things happen in the right order, because when you use method calls, you can't change the order of execution without breaking an expression up into multiple expressions: It always happens from left to right. In order to support code like the above, we'd need to be able to define the following operators: PricePerColumnMm * LengthInMm -> PricePerColumn PricePerColumn * Column -> Money Money - Percentage -> Money This comes in addition to the usual operators that takes the same type on both sides, such as Money + Money, etc. Please note the last one, which is a non-commutative operation (Money - Percentage != Percentage - Money), which wouldn't work in Patricio's proposal, unless the "Associativity" section is rewritten to handle this in a different way. I like Patricio's proposal in that it uses ordinary, non-static methods, but unfortunately, it then runs into this problem, which seems to favour Jan's proposal. With regard to the mechanism for handling this (interfaces, magic methods, or a magic __overload() method), or Sara's proposal for registering overloads, using overload_type(), none of that are deal-breakers for me. Still, as we already have "magic methods" for other things (and interfaces, yes, I know), I'd lean towards implementing these as magic methods, which lets a developer only implement the operations that makes sense in their domain. Also, I think we should distinguish between non-assign and assign operators, giving them different method names, because some types may be expensive to copy, for example a large matrix, so $matrix *= $vector could be way more efficient than $matrix = $matrix * $vector. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
When would the constructor be called automatically? I've used Delphi and you use the inherit verb (or inherited - long time ago - can't remember exactly). In PHP parent::__construct (though I think parent::__METHOD__ would be cleaner as this removes ambiguity on the actual name for all inherited methods). Well, let's look at C++, which I'm most familiar with. PHP is not C++ Ah, I was kind of waiting for that one... :) Yet, that says absolutely nothing about why PHP works the way it does. and speaking of constructors and destrcutors PHP goes morethe Delphi way. If constructors/destructors are not the PHP way, then why even have them? We do not claim to follow any other language precisely, PHP is it's own language with its own feature set. Naturally, but is it unreasonable to think that there's a reason for the way things work in PHP...? And to ask _why_ PHP doesn't let you ensure that a class has its constructor/destructor called? Why implement constructors/destructors in such a way that they may - or may not - be called? Do you feel lucky? Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
From: Marian Kostadinov [EMAIL PROTECTED] Well, PHP is a loosely typed language. You have much more freedom when you write a code. Constructors are not an exception. It is very convinient that you may not call the parent constructor and many people do it, believe me! Why would you not call the base class constructor/destructor? Could you give an example? Regards, Terje 2006/9/15, Terje Slettebø [EMAIL PROTECTED]: From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructorsrequired to be called?
Hi Christian. Thanks for your reply, but I would appreciate it if people read my posting properly, before replying: I have _not_ asked for this to be changed, I have just asked for _reasons_ for the current situation, and pointed out potential problems with it. I think that's reasonable request. Yes, having to explicitly call the base class constructor/destructor allows you to be conscious about calling it. It also allows you to forget it, in the same way that returning error codes (rather than throwing exceptions) means you have to be conscious about handling them. Unfortunately, as doing that requires additional code, it's often not done, either consciously (This function probably always succeeds...), or simply forgotten. If a base class changes, from not requiring a constructor/destructor call, to requiring it, it also means that _all_ client code (much of which you may not control or know of) will have to be changed, as well. Failure to do so leads to silent bugs. The same goes for functions changing to return error codes. Not checking return codes leads to brittle and buggy software, and problems from this is well known, which is one of the reasons for exceptions (which _can't_ be ignored). Or would you perhaps like catching exceptions to be optional, as well...? You know, a little more flexibility... Having to be conscious that you catch it, or else, you'll never know that you've actually got a bug... Regards, Terje From: Christian Schneider [EMAIL PROTECTED] To: Terje Slettebø [EMAIL PROTECTED] Sent: Friday, September 15, 2006 11:38 AM Subject: Re: [PHP-DEV] Re: Why isn't base class constructors or destructorsrequired to be called? Terje Slettebø wrote: Naturally, but is it unreasonable to think that there's a reason for the way things work in PHP...? And to ask _why_ PHP doesn't let you ensure that a class has its constructor/destructor called? Why implement constructors/destructors in such a way that they may - or may not - be called? Do you feel lucky? The main reason I see: Simplicity, i.e. less magic in the language. PHP programmers are taught to a) call the parent contructor if needed and b) not to rely on when destructors are called. Adding a parent::__construct/destruct call is no effort and allows to be conscious about when to call it (after or before you initialized some stuff) or how to call it (modify the parameters for it). Like it or not but I never found it a big limitation so far. But the main reason I'm writing this email is to tell you that it the minds here are set and you won't be able to change that so it's probably better to leave it at that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Terje Slettebø wrote: The above was a contrived example, meant to illustrate the point. What's so bad about it? That it doesn't check the return value? I am not worried about the return value of the method. I am concerned that $this-something is unset yet does not throw a notice. This is only true for properties of objects. Any other variable in PHP does not behave this way. IMHO, PHP should either initialize that variable to a default type and value or throw a notice when you try and use it without setting its value. I completely agree. :) _Then_ I understood you; I thought you meant my example(code) was crap... :) Another weird thing of PHP's implementation of OO is that propagation of constructor calls to the base class is not ensured, something I can't for the life of me understand why, but that deserves its own thread... Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Why isn't base class constructors or destructors required to be called?
Hi all. Another issue. :) As usual, I searched the archive first, but found only a few postings from 2004 on the subject, without much clarification, so I'd like to pose the question again. If this has been discussed, I'd welcome hearing what was the outcome of it. In PHP, unlike other languages with support for OO (such as C++ and Java), base class constructors are not automatically called (or enforced being called). I wonder why this is so? If the answer is flexibility, has the issues arising from this been seriously considered...? This means that if I make a base class Base, which needs to have its constructor and/or destructor called, to be initialised properly, there's currently _no way_ to enforce that, in PHP (that I know of). This means you risk half-constructed and half-destructed objects around, and in that case, program correctness is compromised. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why isn't base class constructors or destructors required to be called?
Hi Johannes. you should look harder: http://www.php.net/~derick/meeting-notes.html#function-require-construct-to-force-calling-the-parent-s-constructor Thanks for your reply, but I've actually seen that one. However, no _reason_ for not allowing/requiring this in userland is given. Only the conclusions: Conclusions: - We add a flag to the class structure to record this - We do not add new syntax for this to userland Reading this again, I'm wondering if I interpret it right in that there will be no way to enforce this in PHP code? If so, why not? Regards, Terje Terje Slettebø wrote: Hi all. Another issue. :) As usual, I searched the archive first, but found only a few postings from 2004 on the subject, without much clarification, so I'd like to pose the question again. If this has been discussed, I'd welcome hearing what was the outcome of it. In PHP, unlike other languages with support for OO (such as C++ and Java), base class constructors are not automatically called (or enforced being called). I wonder why this is so? If the answer is flexibility, has the issues arising from this been seriously considered...? This means that if I make a base class Base, which needs to have its constructor and/or destructor called, to be initialised properly, there's currently _no way_ to enforce that, in PHP (that I know of). This means you risk half-constructed and half-destructed objects around, and in that case, program correctness is compromised. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
(This went to me privately, but in order for this to benefit the discussion,
I reply to the list, as well. Besides, there's now another thread for this,
too)
Hi Richard.
When would the constructor be called automatically? I've used Delphi
and you use the inherit verb (or inherited - long time ago - can't
remember exactly). In PHP parent::__construct (though I think
parent::__METHOD__ would be cleaner as this removes ambiguity on the
actual name for all inherited methods).
Well, let's look at C++, which I'm most familiar with. Here's an example:
class Base
{
protected:
Base(int a) { ... }
};
class Derived : public Base
{
public:
Derived() : Base(123) // Base class constructor called here
{
...
}
}
In C++, the order of construction goes from the top base class to the most
derived class (although using virtual inheritance complicates that a
little), and destruction happens in the reverse order. One important point
is that the all the base class constructors (if any) are called before the
derived class's constructor body (i.e. what's between { and }) is
entered. This way, you may rely on properly constructed base classes, as
well as initialised member variables, in the constructor. The Derived() :
Base(123) syntax is, as may be familiar, an initialiser list, and may be
used to initialise both any base classes, as well as member variables.
With reference to another thread about uninitialised member variables: In
C++, unless these are initialised using the initialiser list, they will be
default-constructed, so they are also in a well-defined state, on entry to
the constructor body. The same goes for any base classes.
Now, what to do in PHP? As PHP is defined, the best might simply be to give
an error/warning/notice, if a base class hasn't been initialised (i.e. had
its constructor called) when the derived class constructor finishes. As PHP
doesn't have concepts like initialiser lists, or default-construction of
base classes and member variables (unless these are explicitly constructed
in these lists), it may not be much point in trying to do it that way in
PHP.
Regards,
Terje
On 14/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
Terje Slettebø wrote:
The above was a contrived example, meant to illustrate the point.
What's
so
bad about it? That it doesn't check the return value?
I am not worried about the return value of the method. I am concerned
that $this-something is unset yet does not throw a notice. This is
only true for properties of objects. Any other variable in PHP does
not
behave this way. IMHO, PHP should either initialize that variable to
a
default type and value or throw a notice when you try and use it
without
setting its value.
I completely agree. :) _Then_ I understood you; I thought you meant my
example(code) was crap... :)
Another weird thing of PHP's implementation of OO is that propagation of
constructor calls to the base class is not ensured, something I can't
for
the life of me understand why, but that deserves its own thread...
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Making ArrayAccess objects more array-like?
Hi all. (Again, I've searched the archives, but haven't found anything on this one) The ArrayAccess interface allows one to essentially overload the index operator [] [1], which is nice, as it makes it possible to implement things like type-checked associative arrays, variants, tuples, etc. However, you can't use it with any of the built-in array functions (such as count(), or the array_*-functions), which means you have to either: 1. Have something like an as_array() member function, returning a reference to the embedded array, and call this every time you need to call one of these functions, or: 2. Implement the functions as member functions on the object. Both of these solutions are rather inelegant, and in particular, 2. leads to unnecessary code bloat, and both gives a different calling convention compared to ordinary arrays, which can surely confuse readers of the code. My question is: Has it been considered changing the standard library functions that take an array as a parameter, to be able to take an object implementing ArrayAccess/IteratorAggregate, also? Would it perhaps be a very large change? That would be understandable, given that it could mean the library having to be able to call into user code (the object being passed). However, this is done elsewhere, too, such as foreach(). I know the inability to return a reference is well known. However, has there come to a consensus about how to solve it (or if)? It tends to trip up code using these arrays a lot... Sometimes, you get no change in the array, as it turns out it operated on a copy of an element, rather than the built-in array. Regards, Terje [1] Since ArrayAccess essentially means overloading the index operator, I'm wondering how this have gone through, since some members of the development team (Andi?) appears to have very strong feelings against operator overloading...? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Const member functions
(This may be considered too radical for some, but I ask, anyway... Also, if
there's a more appropropriate place to ask such questions, let me know, but
as this is the developer's list, it seemed like the right place)
In C++, it's possible to declare member functions const meaning they don't
change the object they operate on. This can help reason about programs,
because if you have something like (PHP syntax):
function some_member()
{
...
$a = $this-f();
$b = $this-g();
$c = $this-h();
...
}
and f(), g() and h() are all declared const, you know the object is still
in the same state as before the functions were called. I was recently bit
by this, when I changed the state in a member function, and later called
that member function, thinking it _didn't_ change the state, and wasted some
time debugging that. Had it been possible to declare your assumption (this
function doesn't change the object), I'd got an error where it did change
the object, clearly showing the erroneous assumption.
Thoughts?
As I'm pretty ignorant about the internals of PHP, I don't know if this is
practical to implement, or whether it might fit with the language.
It's possible to _simulate_ this effekt to some degree, but at the cost of
both syntactic noise and performance: In short, it's a hack. It involves
creating an object at the start of the function definition, taking a
reference to $this, and comparing the new state with a copy of it, in the
destructor (i.e. at the end of the function). However, it's a rather
inelegant solution, with a potentially large performance impact.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
From: Richard Quadling [EMAIL PROTECTED]
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
One of the good things about PHP is the loose typing (1.00 == 1 == 1
sort of thing as I understand it). This has been useful.
I'd say that's debatable. :) Yes, it can make it more convenient to handle
data coming from outside the script (such as forms), but it can also hide
bugs. While it can be argued that conversions between, say, arithmetic types
(int and floats) may be useful, allowing conversion from something like NULL
to empty string, integer 0, etc. (as PHP does) may be going a little over
board, as an uninitialised variable (such as a member variable) may not be
easily discovered.
It's interesting to note that Java (a newer language than C++) actually has
a stronger type system (at least in some respects) than C++: While C/C++
allows things like implicit conversion between int/float/pointer and bool (a
legacy from C), Java does not, and if you think about it, it makes sense to
disallow that, as boolean values are conceptually different from these.
But one of the first things we are told about using PHP ITRW is to
always validate user input and to make sure you only accept what you
know to be valid data.
True, and at least with regard to function calls, with type hinting (as you
mention below), that testing is done for you, so you don't have to, leading
to less code and syntactic noise (and possibly better performance).
We can already use type hinting for arrays and classes for parameters.
Type hinting could be extended to all types for user functions.
I asked about this about 1 1/2 year ago (as well as the possibility of
function overloading - which _would_ be at least theoretically possible, now
that we have type hints), on this list, but got a very negative response to
that... So... I figured the PHP community wasn't ready for that, or didn't
think it fit the language. I still think type hints for fundamental types
could be a good idea, for catching errors early, such as passing NULL to a
function expecting string (as long as it avoids the usual implicit
conversion).
Anyway, with Sara Golemon's operator overloading extension, it's possible to
make your own Integer, Float, String, etc. types, and use them basically as
built-in types, making it possible to use them for type hints.
Even
the possibility of accepting multiple types for a single parameter
could be used to support a mixed type.
One way to do that could be to create a user-defined variant type (or
mixed type, as you say), that may contain a specified number of types.
Yes, I know that in PHP, basically all variables are variants, but with a
class, you may restrict it to just a few specific ones.
Likewise, it's possible to create type-checked tuple types (a sequence of
values, of specified types), and ditto arrays.
As it's mentioned in the user-contributed notes on autoloading, you may even
abuse the autoloader to implement parametric types (like templates in
C++). For example, if you write:
function f(Array_string $value)
{
}
The autoloader may synthesise the Array_string type, from a generic
typed array class, to produce a custom array type that enforces numerical
indexes and string values (the above is really short for Array_int_string,
where int gives the key type, and string gives the value type).
Again, this may be useful for expressing intentions in code, as well as
runtime-enforced conditions.
Recently we had a discussion about parameter overloading on methods.
You can probably use __magic to produce the effect of parameter
overloading.
I'm not sure what you mean by parameter overloading. Do you mean function
overloading? Yes, you can simulate that, using e.g. a dispatch based on
func_get_args(), but it's rather inelegant, compared to real overloading.
Also, it's impossible to overload existing functions in the standard library
(if it was, you could provide your own count(), array_*-functions, etc. for
user-defined array types.
Whilst casting the return type is easy to do, having the return type
as part of the function declaration would be very useful for
auto-documentors.
Not only that, but in my opinion the more important thing that you may
enforce a return type (forgetting to return a proper value from a function
could be caught this way).
As for syntax, I would go with ...
type function f(type $value)
Yes, that's _one_ possibility. Let's see it in all its glory (i.e. with a
lot of other qualifiers):
public abstract SomeClass function f(SomeOther $value)
Hm, maybe. Another alternative might be (closer to C/C++/Java syntax):
qualifiers function return type function name(parameters)
E.g.:
public abstract function Someclass f(SomeOther $value)
It would be useful to also have VOID as a return type, but that may be
open for discussion.
Yes, or perhaps more natural for PHP, null.
But mixed type returns (normal
Re: [PHP-DEV] Making ArrayAccess objects more array-like?
Hi Marcus. long ago we decided against supporting it in the array functions. Ok, thanks. Could I ask what the reasons were (Alternatively get a pointer to the discussion)? Regards, Terje best regards marcus Wednesday, September 13, 2006, 8:39:57 AM, you wrote: Hi all. (Again, I've searched the archives, but haven't found anything on this one) The ArrayAccess interface allows one to essentially overload the index operator [] [1], which is nice, as it makes it possible to implement things like type-checked associative arrays, variants, tuples, etc. However, you can't use it with any of the built-in array functions (such as count(), or the array_*-functions), which means you have to either: 1. Have something like an as_array() member function, returning a reference to the embedded array, and call this every time you need to call one of these functions, or: 2. Implement the functions as member functions on the object. Both of these solutions are rather inelegant, and in particular, 2. leads to unnecessary code bloat, and both gives a different calling convention compared to ordinary arrays, which can surely confuse readers of the code. My question is: Has it been considered changing the standard library functions that take an array as a parameter, to be able to take an object implementing ArrayAccess/IteratorAggregate, also? Would it perhaps be a very large change? That would be understandable, given that it could mean the library having to be able to call into user code (the object being passed). However, this is done elsewhere, too, such as foreach(). I know the inability to return a reference is well known. However, has there come to a consensus about how to solve it (or if)? It tends to trip up code using these arrays a lot... Sometimes, you get no change in the array, as it turns out it operated on a copy of an element, rather than the built-in array. Regards, Terje [1] Since ArrayAccess essentially means overloading the index operator, I'm wondering how this have gone through, since some members of the development team (Andi?) appears to have very strong feelings against operator overloading...? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Terje Slettebø wrote:
I'd say that's debatable. :) Yes, it can make it more convenient to
handle
data coming from outside the script (such as forms), but it can also
hide
bugs. While it can be argued that conversions between, say, arithmetic
types
(int and floats) may be useful, allowing conversion from something like
NULL
to empty string, integer 0, etc. (as PHP does) may be going a little
over
board, as an uninitialised variable (such as a member variable) may not
be
easily discovered.
IMHO, that is covered by === and the NOTICE error level.
Scenario:
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
error_reporting(E_ALL);
$something=new Something;
echo $something-f()+10; // Prints 10.
--- End ---
This will run without any notices, warnings or errors. If we meant to
initialise Something::something to a value, then there's no way to detect
that in f() (other than manual type-checking), since we can't specify the
type for Something::f()'s return type. Had we been able to specify e.g.
int as the return type, the call to Something::f() would give us an error
message, alerting us to the problem.
As the program stands, it has a silent bug...
How would you solve this with === or E_ALL?
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Const member functions
In C++, it's possible to declare member functions const meaning they don't change the object they operate on. This can help reason about programs, because if you have something like (PHP syntax): It would be pretty hard to enforce in PHP - how do you know the object is not changed, without strictly typing all the functions that access it? Like I've mentioned, I don't know how PHP does this internally, so maybe this is hard to detect (or may result in nontrivial overhead). I'm not sure what you mean by strictly typing all the functions that access it: The modification detection would likely have to happen at run-time (not compile-time), due to PHP's dynamically typed nature, so I can't see what typing would have to do with it. Also, while in C++ compiler can benefit from knowing the function is const - i.e. from knowing nothing was changed by it regarding this argument - PHP engine hardly can do it. Much, if not almost all, of the benefit of const is about program correctness and easier reasoning about programs (if you know something is const, including variables, you know you can rely on them not having been changed, even a zillion lines below where they were defined), i.e. advantages for the _developer_, foremost. It _might_ give some possibilities of optimisation, in a statically typed language, but that's more of a side effect. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Re: __autoloading and functions
Hi François. I think this sounds like a great idea. :) We do something similar with our class loader, in that it scans a lib-directory and its subfolders, building a map of class name to filename (it doesn't open the files - it only builds the map based on file naming convention, allowing it to infer the class name from the file name, if a file contains a class) and storing it in the session. Yet, something that didn't have to be rebuild at session startup would be even better. Of course, one could serialise this information, but then it becomes important that it updates it when there are relevant file changes (like your CLI program can do). Regards, Terje - Original Message - From: LAUPRETRE François (P) [EMAIL PROTECTED] To: [EMAIL PROTECTED]; internals@lists.php.net Sent: Tuesday, September 12, 2006 1:01 PM Subject: Re: Re: __autoloading and functions Yes, the trivial answer is to name each file after the symbol it contains, but it limits to one symbol per file (and I was talking about autoloading constants ! :-). Once again, if we don't propose a smarter autoload manager, extending the autoload feature to functions is not very interesting because, for most PHP programmers, it won't make their task easier (and it won't allow to autoload extensions, which would be a big step forward). I would be glad if people interested in this subject could have a look at an autoload manager I have written and which could, IMHO, solve most of these problems. It contains two parts : a CLI program to scan source files and extensions and store their symbols in map files, and a runtime resolver which will use these files. A map file can contain symbols for any number of source or extension files allowing, for instance, to put only one map file in the extensions directory to store the symbols of every extensions present on the host. As there is no hook at this time in the PHP engine to autoload functions and constants, their resolutions must be explicitely requested before using the symbol but, if the autoload feature was extended to these symbol types, the autoloader would be completely transparent to the client programs. Of course, it is written in PHP today but it would be quite easy to rewrite it in C and integrate it to the core. If it was integrated to the core and if we added a cache to keep symbol maps in memory, I am sure that the speed up due to JIT loading would balance the autoloading overhead. Please tell me what you think about it. Regards François Terje Slettebø wrote: In either of the above cases, you specify where a function belongs, both where it's defined, and where it's used (either through full qualification, or a shorter one, using import). I'm not arguing for a function to magically become a part of a class/module/whatever, if you thought so Then the question is how do you think this function would be used? That's a very good question... One simple answer would be to have one file per function, and have it work like typical class autoloaders. However, that could be too much overhead (on many levels), having a lot of small files, that conceptually belong together. Maybe function autoloading isn't such an obvious feature, after all (which was one reason for bringing it up - getting the pros and cons of it. By the way, I've now also read in on the archive of this and the other issues having been mentioned in this thread, such as namespaces). Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
From: Brian Moon [EMAIL PROTECTED]
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
error_reporting(E_ALL);
$something=new Something;
echo $something-f()+10; // Prints 10.
If you can't trust the return values of your methods, I would use:
$var = $something-f();
if($var!==NULL){
echo $var+10; // Prints 10.
}
Right... And you can always use return codes, instead of exceptions or
trigger_error(). The problem is that there's nothing that _enforces_ this
checking, and since it adds verbosity, it's typically not done. If you don't
believe me have a look at some of all of the C code out there, which
typically to a large degree don't check return values (and it shows...
Programs segfaulting and the like, if something unexpected happens), as it
makes the program convoluted and messy, and is easily forgotten. It's for
reasons like this that exceptions (and possibly trigger_error()) were
invented in the first place.
It's similar with the example above: Type-checked return values means you
don't have to write all these tedious manual checks, just to ensure program
correctness (and had the return type hint been mandatory, there's no way you
could forget it or not bother with it, either)..
However, its crap like this that reminds me why I don't use PHP OOP for
all my code. I can find no non-OOP code that behaves this way.
The above was a contrived example, meant to illustrate the point. What's so
bad about it? That it doesn't check the return value? Well... having to
check the return value, to ensure things didn't go wrong is something I left
a looong time ago, when I was programming C, before I started with C++ and
Java, which gives better ways of handling this, and have only had to take it
up again, in PHP.
Even my
favorite PHP trick, using settype() to initialize vars, does not set the
var to NULL.
settype() is still a manual operation - there's no way to automatically
guarantee initialisation. In a language like C++, the class members are
default-initialised, unless you explicitly initialise them, so there's no
way you can forget it or ignore it. The result: More robust programs.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Return type hints
Hi again. To something different: I've read [1] that return type hints for functions have been considered for PHP 6, possibly even planned. In [1], it says: We will add support for type-hinted return values. I've searched the archives, but haven't found much on this since about a year ago. Does anyone have the latest on this? Is it planned, dropped, over somebody's smoking carcass, ;) or what? I've also tried the latest PHP 6 dev-version, a while ago, but it seems it's not in there, yet, at least. If not dropped, have a syntax for this been agreed on? Regards, Terje [1] http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
Hi Marcus.
Thanks for replying. Yes, I understand that very well, having been involved
in open source projects, myself, as well [1]. If I felt really strongly for
this one, I could do it, myself. :) I was mostly just interested in knowing
if this one was still a go. In our systems, we've prepared for it, thus:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
By the way, I appreciate all the work that you and the other developers are
doing for PHP.
Regards,
Terje
[1] I've been involved in Loki (http://sourceforge.net/projects/loki-lib),
co-authoring the port of the library to Borland C++ (which was non-trivial,
given that Loki uses cutting-edge C++), as well as having been project
admin. Another project I'm involved in is the C++ Concept Traits Library
(http://www.neoscientists.org/~tschwinger/boostdev/concept_traits/libs/conce
pt_traits/doc/), which is a library to implement concepts (like Haskell's
type classes) in C++. Unfortunately, I haven't had a chance to do anything
with either of these for a long time, due to work, so I full well understand
that people may be busy with other things. :)
- Original Message -
From: Marcus Boerger [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Tuesday, September 12, 2006 11:00 PM
Subject: Re: [PHP-DEV] Return type hints
Hello Terje,
at some point i might find time to do something. I guess all others who
could do something in that area are occupied either by unicode or
namespaces. This means we still have this on the todo. We are only open
source and all do stuff in our free time
best regards
marcus
Tuesday, September 12, 2006, 11:40:54 AM, you wrote:
Hi again.
To something different: I've read [1] that return type hints for
functions
have been considered for PHP 6, possibly even planned. In [1], it says:
We
will add support for type-hinted return values.
I've searched the archives, but haven't found much on this since about a
year ago. Does anyone have the latest on this? Is it planned, dropped,
over
somebody's smoking carcass, ;) or what?
I've also tried the latest PHP 6 dev-version, a while ago, but it seems
it's
not in there, yet, at least.
If not dropped, have a syntax for this been agreed on?
Regards,
Terje
[1]
http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
Maybe a dump question, but wouldn't it get considered only, AFTER PHP has found that the function does not exist? Technically, this can be done - i.e. engine can be patched so that instead of throwing an error or refusing the call it would call appropriate function which would allow for autoloading. However, I think autoloading functions if conceptually wrong. One rarely keeps functions individually separated in different files (while this is routinely happening - and is recommended - for classes). So, if you want to autoload functions you would either have to build complex tables of where each function lives or organize them in some well-defined modules. Such modules are called classes in OO-speak Or namespaces... Or just plain modules. Classes is not the only way to group things, and may not be the best (namespaces can typically be re-opened, so functions and classes belonging to a namespace can span several files, instead of everything having to be in _one_ file). , so if you have a group of functions that are united by purpose and you want to autoload - why not to make a class out of them? Why? Besides the above, because you may want to be able to call a function like: f(); and not: SomeClassToWrapItAll::f(); ... Please, people: The availability of free (non-member) functions in PHP (as in C/C++) is one advantage it has over Java, where everything _has_ to be a class. So in Java, instead of being able to write sqrt(number), you have to write Math::sqrt(number). Always. And one small plea: If namespaces are added to PHP, please don't add something like C++'s argument-dependent lookup: It has caused no end of problems in that camp. :) Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
Or namespaces... Or just plain modules. Classes is not the only way to group things, and may not be the best (namespaces can typically be Oh, of course it's not the only way. It's the only way native to PHP though. Yes. re-opened, so functions and classes belonging to a namespace can span several files, instead of everything having to be in _one_ file). Thus, how do you suppose autoloading function would know which file to load? We are back to the complex ugly logic argument. That's not something I've thought through: I just wanted to point out that classes are not the only way to group things. I've quite recently started to read the postings, here, but I intend to read up on the relevant discussions in previous postings to the list, to know what has been discussed, and what has come from it. Why? Besides the above, because you may want to be able to call a function like: f(); and not: SomeClassToWrapItAll::f(); You may call the class x if you like one-letter names :) No thanks, I prefer readability. :) Besides that, saving keystrokes was never a top priority for PHP Uah... (see how elaborate function names standard modules have). Yes... Wonderful, isn't it? :) Sorry, like I said, I'll read up on previous discussion of things like namespaces, before jumping into a discussion about them. Still, just one observation...: Verbosity rarely lead to clarity, it's rather the other way around. Keystrokes are cheap, clarity of the code isn't. Clarity is very important, but always spelling things out in full may lead to less clear code. However, I'd think this is a discussion that is more appropriate at php-general... I am just saying trying to make functions behave like they belong to class or module without either saying class or module (i.e. include) may not be the best idea to support. I'm not sure I follow you... In for example Java, you have packages (modules), and you may either use the full name of a class all of the time, such as java.lang.Math::sqrt(...) or Math::sqrt(...) (or even sqrt(...), in a language supporting free functions). You seem to argue for the first one, for clarity... In either of the above cases, you specify where a function belongs, both where it's defined, and where it's used (either through full qualification, or a shorter one, using import). I'm not arguing for a function to magically become a part of a class/module/whatever, if you thought so (there's way too much magic in PHP as it is, and the separation between what implementors can do, and what userland is allowed to, is not a separation I like, either, but that's another discussion). Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
On 9/11/06, Terje Slettebø [EMAIL PROTECTED] wrote: Please, people: The availability of free (non-member) functions in PHP (as in C/C++) is one advantage it has over Java, where everything _has_ to be a class. So in Java, instead of being able to write sqrt(number), you have to write Math::sqrt(number). Always. Actually, Java recently added static import to deal with that very annoyance ;) Right. Well, to me, having to wrap everything in a class, just because you don't have free functions, seems like more of a workaround than anything else, and the static import a kludge to make that less inconvenient (conceptually, it doesn't make a lot of sense to me to import some class's static members into a context...). Besides, it forces you to define everything in _one_ file (unless _that_ has been changed, as well). I'm reminded of that, after having learned Java at college, and taking up C++ again, after it, I had to deprogram myself of Javaisms: I tended to use a class for everything, even if it made my design more complex and tighter coupled than necessary. For example, if I needed some functions that didn't naturally belong in a class (such as various utility functions), I'd wrap them as static members in a class called Utility. When reading up on C++, again, I realised that this was absolutely not necessary: You could simply define them as free functions in a namespace called utility... That way, they may be called unqualified (if imported with using), and may span several files. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
In either of the above cases, you specify where a function belongs, both where it's defined, and where it's used (either through full qualification, or a shorter one, using import). I'm not arguing for a function to magically become a part of a class/module/whatever, if you thought so Then the question is how do you think this function would be used? That's a very good question... One simple answer would be to have one file per function, and have it work like typical class autoloaders. However, that could be too much overhead (on many levels), having a lot of small files, that conceptually belong together. Maybe function autoloading isn't such an obvious feature, after all (which was one reason for bringing it up - getting the pros and cons of it. By the way, I've now also read in on the archive of this and the other issues having been mentioned in this thread, such as namespaces). Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] __autoloading and functions
Hi all.
I don't know if this has been discussed before (I've not found it from doing
a search), but if it has, please provide me with a link to the discussion.
__autoload() is very convenient, but it has one problem: While classes
defined in the __autoload() function (via an include) are accessible
globally, any functions being included are not accessible outside the
__autoload() function, making them completely inaccessible to the rest of
the system. This means that if you have a file containing a class, as well
as one or more associated functions, you won't be able to use the functions,
if the file containing the class and functions is loaded using
autoloading...
I've not found a workaround for this (except reintroducing
include_once/require_once, which defeats the whole purpose of
autoloading...), are others also experiencing problems with this, and if
not, do you a) not use any functions, or b) manage some other way?
Has there been considerations for solving this in some way?
Example:
--- email_address.php ---
class EmailAddress
{
public function __construct($address) { ... } // Check if string contains
a valid email address
private $address;
}
function email_address($address)
{
return new EmailAddress($address);
}
-
You may then use this like:
$address=email_address(some string expression);
to make the conversion to EmailAddress less obtrusive (simulating implicit
conversion to user-defined type).
However, this doesn't work with autoloading, so you have to either manually
include the above file, or use new directly:
$address=new EmailAddress(some string expression);
In other words, this function is not a candidate for making it a method.
The problem in this particular example would go away if there was a way to
implicitly convert from fundamental types to user-defined types, but that's
another discussion...
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: __autoloading and functions
Hi Hannes.
Ok, so I was wrong about the cause of the symptom, good - so this is
instead another problem: No autoloading of functions... I tried a similar
example, where you switch the order of new foo() and bar() around, and
it fails, as it doesn't find the definition of bar(), since class.php hasn't
been included at this point...
Ok, new question: Autoloading of functions... Has it been considered? Any
fundamental problems with it? (Again, except for others requesting the same,
I've not found anything else about it, so pointers to any previous
discussion of this would be appreciated)
Remember that in my example, I called a factory function to get an
instance of the class, and as you show, it's possible to get that - _after_
you've instantiated the class some other way (or have it call __autoload()
in some way), but in the first call to that function, you typically haven't
instantiated the class, before...
Regards,
Terje
- Original Message -
From: Hannes Magnusson [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Sunday, September 10, 2006 4:44 PM
Subject: Re: __autoloading and functions
Hello Terje
What are you talking about?
--class.php--
?php
class foo {
}
function bar() {
print Hello World\n;
}
--foo.php--
?php
function __autoload($class) {
include class.php;
}
new foo();
bar();
print hello world;...
-Hannes
On 9/10/06, Terje Slettebø [EMAIL PROTECTED] wrote:
Hi all.
I don't know if this has been discussed before (I've not found it from
doing
a search), but if it has, please provide me with a link to the discussion.
__autoload() is very convenient, but it has one problem: While classes
defined in the __autoload() function (via an include) are accessible
globally, any functions being included are not accessible outside the
__autoload() function, making them completely inaccessible to the rest of
the system. This means that if you have a file containing a class, as well
as one or more associated functions, you won't be able to use the
functions,
if the file containing the class and functions is loaded using
autoloading...
I've not found a workaround for this (except reintroducing
include_once/require_once, which defeats the whole purpose of
autoloading...), are others also experiencing problems with this, and if
not, do you a) not use any functions, or b) manage some other way?
Has there been considerations for solving this in some way?
Example:
--- email_address.php ---
class EmailAddress
{
public function __construct($address) { ... } // Check if string
contains
a valid email address
private $address;
}
function email_address($address)
{
return new EmailAddress($address);
}
-
You may then use this like:
$address=email_address(some string expression);
to make the conversion to EmailAddress less obtrusive (simulating
implicit
conversion to user-defined type).
However, this doesn't work with autoloading, so you have to either
manually
include the above file, or use new directly:
$address=new EmailAddress(some string expression);
In other words, this function is not a candidate for making it a method.
The problem in this particular example would go away if there was a way to
implicitly convert from fundamental types to user-defined types, but
that's
another discussion...
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and functions)
Hi Marcus.
Thanks for the replies, both of you. I've solved this particular problem by
having all these little functions in a file that gets included for all files
that need it.
The speed reasoning put aside we also found that procedural techniques
should not mix too much with the object oriented features.
Could I ask why not?
I can give my own thoughts to the opposite: I (and much of the programming
community, it seems) have come to that it's a perfectly reasonable way to
program, where you use the best abstractions for the task (ironically, PHP
is better than Java in this respect, as Java doesn't support free
functions). This goes under the name of multi-paradigm design
(http://www.artima.com/weblogs/viewpost.jsp?thread=167119), and aims at
avoiding the myopic view people tend to get when only one paradigm is
available to them (or familiar to them).
In fact, combining paradigms is what gives MPD much of its power, as it
enables you to do things that no single paradigm, by itself, can do.
Trying to shoehorn everything into _one_ paradigm (whether it's procedural
programming, OO, functional programming, or whether) may lead to some very
contorted designs... To paraphrase a well-known phrase: If all you know is
OO, everything will look like an object (whether or not it makes any sense).
However, I guess this discussion may not belong on internals... However, to
use this concrete example, could you tell me why e.g.:
$value=Something::something(something else); // A related issue: Is this
even OO? We're not operating on an object...
would be better than:
$value=something(something else);
The latter is less to type, which is much of the reason for it in the first
place, as well as it looking like a C++-style cast, which is how it behaves.
The first version really isn't a better alternative to new
Something(something else).
Regards,
Terje
P.S: As an aside: Why is everybody (?) replying to both the list _and_ the
poster? If you post, isn't it safe to assume you're actually on the list, or
am I missing something?
- Original Message -
From: Marcus Boerger [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: Hannes Magnusson [EMAIL PROTECTED];
internals@lists.php.net
Sent: Sunday, September 10, 2006 5:35 PM
Subject: Re: [PHP-DEV] Re: __autoloading and functions
Hello Terje,
it hasbeendiscussed and the conclusion is that it isfar too much of a
slowdown for every function call and thus we are not going to implement
it. The speed reasoning put aside we also found that procedural techniques
should not mix too much with the object oriented features.
bes regards
marcus
Sunday, September 10, 2006, 5:30:54 PM, you wrote:
Hi Hannes.
Ok, so I was wrong about the cause of the symptom, good - so this is
instead another problem: No autoloading of functions... I tried a
similar
example, where you switch the order of new foo() and bar() around,
and
it fails, as it doesn't find the definition of bar(), since class.php
hasn't
been included at this point...
Ok, new question: Autoloading of functions... Has it been considered?
Any
fundamental problems with it? (Again, except for others requesting the
same,
I've not found anything else about it, so pointers to any previous
discussion of this would be appreciated)
Remember that in my example, I called a factory function to get an
instance of the class, and as you show, it's possible to get that -
_after_
you've instantiated the class some other way (or have it call
__autoload()
in some way), but in the first call to that function, you typically
haven't
instantiated the class, before...
Regards,
Terje
- Original Message -
From: Hannes Magnusson [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Sunday, September 10, 2006 4:44 PM
Subject: Re: __autoloading and functions
Hello Terje
What are you talking about?
--class.php--
?php
class foo {
}
function bar() {
print Hello World\n;
}
--foo.php--
?php
function __autoload($class) {
include class.php;
}
new foo();
bar();
print hello world;...
-Hannes
On 9/10/06, Terje Slettebø [EMAIL PROTECTED] wrote:
Hi all.
I don't know if this has been discussed before (I've not found it from
doing
a search), but if it has, please provide me with a link to the
discussion.
__autoload() is very convenient, but it has one problem: While classes
defined in the __autoload() function (via an include) are accessible
globally, any functions being included are not accessible outside the
__autoload() function, making them completely inaccessible to the rest
of
the system. This means that if you have a file containing a class, as
well
as one or more associated functions, you won't be able to use the
functions,
if the file containing the class and functions is loaded using
autoloading...
I've not found a workaround for this (except
Re: [PHP-DEV] Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and functions)
Hi Pierre. P.S: As an aside: Why is everybody (?) replying to both the list _and_ the poster? If you post, isn't it safe to assume you're actually on the list, or am I missing something? It is a common usage here. Some uses nntp, other mails (and filters, etc..). Ok. It's just that it's very unusual for mailing lists (at least the ones I have experience with), but whatever. It is also nice to do not start a new thread for no obvious reason but having another topic, it makes a mess out of the archives and is harder to follow. I'm afraid I didn't understand your point. When you say start a thread, do you mean changing the subject line (as I did)? It's my understanding that people in general prefer that you change the subject line, if the topic changes, as it otherwise makes it much harder to follow the discussion... (and you may have to wade through a lot of postings having nothing to do with the subject line, or miss an interesting discussion, for the same reason). But then again, maybe also these things work differently here, than other places... :) Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Andrei Zmievski wrote: Attention: you have posted C++ template code on PHP mailing list. Please pay a $100 fine immediately and carefully proceed to the exit. Luckily my peril sensitive sunglasses turned black at the first line before I even managed to read the template part of the code :-) To illustrate its use, I can give a simple example in C++: Now that's one of the funniest jokes I've read on the internals list in quite a while (-:C Did you note I wrote simple (in quotations)? To a seasoned C++ developer, it's rather ordinary/modern C++ code, but it may not be to others. And now we all go and quickly wash our brains with soap so we don't get evil dreams keeping us up at night. I see you're not ready for this. Any language, if you're not familiar with it and its idioms, may seem complicated (and in your case may give you evil dreams, apparently). However, what you may see as complicated, people in the know see as powerful abstractions, which may lead to simpler to understand code (than without them), again, if you know the language. However, I see that people here freak out when they see C++ code (like I said, rather different to if someone presented code in another language - any language - at a C++ forum), so it's pointless to continue with this here. It was meant to illustrate a point, but that was apparently missed completely. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Andrei Zmievski [EMAIL PROTECTED] Attention: you have posted C++ template code on PHP mailing list. Please pay a $100 fine immediately and carefully proceed to the exit. Hehe... I do hope this is a joke (it would seem rather closed-minded, otherwise). I don't think anybody would have bothered if anyone posted PHP code on e.g. comp.lang.c++(.moderated), in order to illustrate a point. That would be stupid. sigh I tried. Perhaps you can return your sense humor for a refund? Yeah, follow it up with an insult; that'll do lovely. If you had some insight into human nature, you'd know that humour is very subjective, and given the feedback I've got from others in this thread (which have _not_ been jokes), it's rather hard to see what's a joke and what's not. Let me explain: Although I understood that the literal thing you wrote above was of course a joke, my question was meant to see whether there was a serious side to the joke, as well. In other words, if people reacted negatively to this (and, judging from other reactions, it seems so, or at least, they concentrated on the code, rather than my point illustrated with it). I've been known to have a good sense of humour. However, I'm also sensitive, so when I don't know if something is meant as a joke or not, I don't find it amusing. Apparently, this was something you didn't understand, at all, and instead insult me about something you know _nothing_ about. What have I done to you, to get an insult from you? How would you feel it if someone else said this to you? A friggin' immature thing to say. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
From: Stanislav Malyshev [EMAIL PROTECTED] TSNo, you don't have to go that far. For starters, one could allow function TS(and possibly operator) overloading, based on type hints. The following is TSlegal PHP5: That will already open the can of worms. And make each function call to go through all the hoops of signature matching. Yes, that is a concern, especially when it's done at run-time. TSoverload resolution. However, how much on an impact this would have on TSexecution speed remains to be seen. Exactly. Do you have any base to claim the speed impact would not be serious? Bring it forward. No, which is why I said that it remains to be seen what impact it would have, which means I'm not claiming anything one way or the other. TSIt was a reaction to the oft-mentioned argument that essentially says: We TSdon't need more advanced features. I got that feeling when you said Using Nobody ever said we don't need more advanced features. You know perfectly it is not true. What was said is that we probably don't need *this particular* feature. This has no relation to discussion of any other feature or discussion about having features in general. True. Anyway, there have been requests for ending this sub-thread on overloading, etc., so I suggest that any further discussion, should it be wanted, is done off-list. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
(I don't mind this discussion, but as several have asked for this subthread
on overloading be ended, it may be best to do so)
On Thu, 2005-02-03 at 19:58, Terje Slettebø wrote:
From: Stig S. Bakken [EMAIL PROTECTED]
Oh, and the comment about Code should be readable, not cuddly-cute:
Operator overloading is about being able to express your intent clearer in
the code - leading to _more_ readable code than the corresponding function
alternative (see my arithmetic example in another posting). It has nothing
to do with cuteness, and everything to do with being to express your
intent
clearly in the code.
My take on this is that you are, in many more cases than not, able to
express your intent much clearer with good method names. This is
especially true if operator overloading were not part of the language
initially. Your example with complex math is an exception.
You're entitled to your opinion, of course.
Please explain how you see operator overloading making functional
programming possible/easier in PHP?
By enabling the creation of function objects, which may hold state (unlike
functions, unless you use static). One typical feature of functional
programming languages is the ability to do partial application, i.e.
giving a function less than the arguments it needs, yielding a function with
some of the arguments bound. To illustrate its use, I can give a simple
example in C++:
#include iostream
class plus
{
public:
int operator()(int a,int b) { return a+b; }
};
templateclass T
class apply1
{
public:
apply1(int v) : bound_1st(v) {}
int operator()(int b) { return T()(bound_1st, b); }
private:
int bound_1st;
};
int main()
{
std::cout plus()(1,3) \n;
std::cout apply1plus(1)(3) \n;
}
The first line of main() creates a plus object (plus()), and calls its
overloaded operator() with 1 and 3, giving 4. The second line creates an
apply1 object (taking plus as a type parameter, and 1 as a constructor
parameter - apply1plus(1)), and then its overloaded operator() is called
with 3. As the first parameter, 1, is bound by apply1, the result is,
once again, 4. So the above prints 4 4 (separated by newline).
apply1plus(1) creates a function object which has bound one of plus'es
parameters, which means it becomes a 1 + ? function, effectively, or in
other words, a partial application of the plus function (object).
Naturally, you may get a similar effect in PHP by using named member
functions rather than operator(). As another poster pointed out, $object()
already has a (different) meaning.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Derick Rethans wrote:
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Derick Rethans wrote:
This adds operator overloading to user classes?
Yes, have a look at Johannes' Complex example [1].
Okay, mega Yuck then. Although it looks cool, I consider it as a bad
practise. It confuses the hell out of people that they can add two
objects. Use C++/Java if you want this...
I couldn't agree more. I like PHP not because it is the most compact or
flexible of all languages but because the syntax is quite simple.
Try explaining someone who just learned PHP and doesn't know your code
where to find the implementation of
$c = $a + $b;
as opposed to
$c= $a-add($b);
or
$c = Complex::add($a, $b);
If $a is an object of a class, then they would both be in the class
definition. One is called add, and the other is called operator+. What's
the problem with that?
Another little thought how confusion can easily happen with operator
overloading: $b = $a + 42; works but $b = 42 + $a; doesn't, i.e. the
overloaded addition isn't commutative.
It would if operator overloading was allowed on free functions (as it is in
C++). E..g:
function operator+(complex $a, complex $b)
{
return new complex($a.real + $b.real, $a.imag + $b.imag);
}
The binary operators are recommended to to free functions, for this reason,
in C++.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Derick Rethans wrote:
This adds operator overloading to user classes?
Yes, have a look at Johannes' Complex example [1].
Okay, mega Yuck then. Although it looks cool, I consider it as a bad
practise. It confuses the hell out of people that they can add two
objects.
That's only confusing if you don't know that operator overloading is
possible. In C++, it's perfectly natural to be able to e.g. add values of
user-defined types. It also enables generic code, such as:
function some_calculation($num1, $num2)
{
$num1+=1;
$num2+=num1;
...
}
This would then work for any object (built-in type or user-defined type
(class)) having operator+= defined.
Why this would be confusing is beyond me... Could you enlighten me?
Specifically, do you find the following:
$result=$c1.multiply($c2).divide($c1.add($c2));
less confusing than:
$result=($c1 * $c2) / ($c1 + $c2);
?
Use C++/Java if you want this...
Why would it be ok there, but not in PHP? It also exists in other scripting
languages, such as Python and Perl.
BTW, as another poster pointed out, it doesn't exist in Java, either, except
for the + exception for strings. I think omitting that is a case of
throwing the baby out with the bath water. Yes, used incorrectly, operator
overloading can be confusing, but that's also the case for more or less any
language feature, and we don't ban them. It's no less confusing having the
member function add() perform subtraction, as it is to let the + do
that.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Derick Rethans wrote:
Use C++/Java if you want this.
Java does not support operator overloading.
So, that means PHP shouldn't get it either, right? ;-)
As I already asked in the past, I'm in favour to have them for
intern usage only (understand used by extension).
Internal in what way? And why?
As we already for
propoerties read or write. For those who do not know, you have no
way to know that you in a ++, -- call. At least for ++,-- and
friends.
I'm not sure I understood the above, but if I understood it right, why would
that be?
class SomeClass
{
function operator++() // #1
{
return ++$this-value;
}
function operator($dummy) // #2 ***
{
return $value++;
}
var $value;
}
$object=new SomeClass();
++$object; // Calls #1
$object++; // Calls # 2
(***) This is how it's done in C++ (actually, a dummy int parameter), which
is a bit of a hack, to be able to specify both the pre- and
post-increment/decrement operators. #2 (and postfix --) is the odd one,
since they are the only postfix operators among the operators.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
SB patch [1] by Johannes Schl?ter that has been floating around for a SB while? 1. I personally don't think operator overloading is a good idea. It doesn't add you anything you couldn't do without it the same way - it's pure syntax sugar. As someone said, Syntactic sugar matters, or we'd all be writing assembly code. :) Besides, it's not just syntactic sugar: See my other posts in this thread, but briefly, they enable generic code - code that may be used by both built-in and user-defined types, without knowing or caring which is which. That is indeed powerful, and most of the advances in later years in C++ has come in the area of generic programming (where templates are used for this, since types are checked at compile-time). And it really ruins the readability of the code - go figure what $i++ means now, in absence of any type delcarations. If it's sensibly implemented, it should increment $i (whatever that is), and return the previous value. This is no more confusing than increment_and_return($i), where you may also need to look at the function definition. I find the first version much clearer, though. 2. The referenced patch raises doubts - why it allows to override / but not %, for example? What with all other operators? I agree that if operator overloading was added, it should be available for all operators where it makes sense. Why add would work as $foo + 1, but 1 + $foo won't? Both would work if we allow operator overloading on free functions. But that may be too radical for some people, it seems. Just to drive the point home: Operator (and function) overloading is not an OO feature. However, it's often found in OO languages, and complements OO well. It's a different kind of polymorphism. Will + be non-commutative operation from now on? There shoudn't be a need for that. We should try to avoid such surprises. What with assign-ops - it would leak memory in this case? Why would it do that? Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
TSIf $a is an object of a class, then they would both be in the class TSdefinition. One is called add, and the other is called operator+. What's TSthe problem with that? The problem is that you can't really know what $a is - PHP is typeless. When you say typeless, i think you mean not statically typed. I've been through this discussion elsewhere - a variable will at any one time have a well-defined type (or unset), which you may overload on, so the language is definitely not typeless. An example of a typeless (or single type language, if you like) language is BCPL, where there was only one type, the machine word. As mentioned in another posting, operator overloading also exists in other dynamically typed languages, such as Python and Perl. You'll have to trace all the program up to $a's assignment and hope you didn't miss reassignment on the way. Yes, variables are dynamically typed, but when you call a function, you typically have an idea of what its type is. Otherwise, the type hints for PHP 5 would be pointless! By your argument. TSIt would if operator overloading was allowed on free functions (as it is in TSC++). E..g: You can't do it like in C++, because in C++ function signature includes argument types, and in PHP it does not. That's right, so we'd really need function overloading to be able to use the free function form, which I think is another good idea (function overloading). I.e., you can't write two operators - one for complex+int and one for complex+complex. In general, it's too much trouble for too little gain Well, you're certainly entitled to your opinion, but others, including me, think it's worth it. - except for select things like complex and matrices (and maybe two more things like this) I don't see any value in having, say, + overloaded. Using good old methods will never fail you. Neither will assembly code. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Stig S. Bakken [EMAIL PROTECTED] On Thu, 3 Feb 2005, Sebastian Bergmann wrote: Andi Gutmans wrote: Comments/Flames/Praises to this list :) Just curious: Have you considered adding the operator overloading patch [1] by Johannes Schlüter that has been floating around for a while? Operator overloading in PHP? Over my smoking carcass! PHP 5 returns object handles, which lets you do _exactly_ the same thing, only without the obscurity. You mean $a + $b? add($a, $b) is _not_ exactly the same thing. Nobody needs overloaded operators. Code should be readable, not cuddly-cute. Hm, I'm surprised by this response from someone who's name I recognise as an active PHP contributor. The answer strikes me as either arrogant and/or ignorant (note: I'm not saying you are that, but that's how the reply comes across, given what what operator overloading is about). As I've pointed out in other postings in this thread, operator overloading is about much more than just syntactic sugar. In C++, for example, it enables important things such as function objects (being able to pass an object to a function, for example, and have it behave as a function, enabling functional programming, as well). This is not possible (possibly without jumping through major hoops) in PHP. However, I see from this and other threads, that there's not much chance of evolution of PHP to support more advanced features (which are common in other scripting languages, as mentioned). It seems basic OO support is about the only thing the PHP community can handle when it comes to expressiveness in the language. Oh, well. Oh, and the comment about Code should be readable, not cuddly-cute: Operator overloading is about being able to express your intent clearer in the code - leading to _more_ readable code than the corresponding function alternative (see my arithmetic example in another posting). It has nothing to do with cuteness, and everything to do with being to express your intent clearly in the code. But it seems the community isn't ready for this. Too bad. Maybe in PHP 10. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
From: Stanislav Malyshev [EMAIL PROTECTED] TS(***) This is how it's done in C++ (actually, a dummy int parameter), which TSis a bit of a hack, to be able to specify both the pre- and In C++, functions differ by argument. In PHP, they don't. Yes, but a different way might be used for PHP. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
TSAs someone said, Syntactic sugar matters, or we'd all be writing assembly TScode. :) Someone was wrong. There are syntax constructs that allow to reduce complexity of the code, and there are constructs that make the code have the same complexity but look prettier to the eyes of the writer. It depends on how you define complexity. Are the following two lines equally complex to you: 1) $result=$c1.multiply($c2).divide($c1.add($c2)); 2) $result=($c1 * $c2) / ($c1 + $c2); They sure aren't to me. Moreover, they are not the same: operator overloading enable you to use infix notation, whereas functions use prefix, only. The latter is syntax sugar. It is important, but not at the price of making code harder to read If it makes the code harder to read, it's not much of syntactic sugar, is it? I can't see why operator overloading should make it harder to read. The only thing I can think of is that, given that there's no type declarations in PHP, it may be hard to know, looking at a line, what the type of the variable is. However, in a properly written program, the actual type may not be that important. Take for example: $sum = $money1 + $money2; Whether or not the variables are built-ins or from a money/currency class, should matter little to your understanding of this code. or language slower to work. Why would it become slower. As you say, the notation is essentially syntactic sugar for a function call, and should be equally fast. TSBesides, it's not just syntactic sugar: See my other posts in this thread, TSbut briefly, they enable generic code - code that may be used by both TSbuilt-in and user-defined types, without knowing or caring which is which. I don't see how using $a + 1 is better than using $a-add(1) in this regard. What if you want to add two variables? TSThat is indeed powerful, and most of the advances in later years in C++ has TScome in the area of generic programming (where templates are used for this, TSsince types are checked at compile-time). C++ is typed Statically typed, yes. , so you need to jump trhough various hoops to make it work in non-typed way, while preserving it's typedness benefits. Yes, if you want to use C++ in a typeless/dynamically typed way, you need to use things like templates, or a variant type. However, since those are available, you get the benefits of something similar to type inference, and also static type checking. PHP works differently - you don't have benefits and need no hoops. You don't have benefits of what? (Should don't have been omitted?) TSThis is no more confusing than increment_and_return($i), where you may TSalso need to look at the function definition. I find the first version much TSclearer, though. Well, I guess it's the matter of personal taste. For me, the second is the clear winner - you can name function after what it actually does and not hope that everybody knows ++ makes an iterator go to the next element. Oh, well. Programming by guesswork is always hard. A point with programming languages is that once you've learned them, and their abstractions, it makes it easier for you to program. Operator overloading is no different. TSBoth would work if we allow operator overloading on free functions. But that It can't be done without making PHP strict-typed - you coldn't really distinguish which function is to be called, and you couldn't distinguish between functions with same name. Yes, you'd need function overloading (we already have type hints, which could be used for the overload resolution). Even if you could - how many operator+'s you are willing to write? For all type combinations? That depends on what you want. I can't see how this question is different from How many member functions (like add()) are you willing to write?? Or what is supposed to happen if + called for type combination that you don't have an operator for? An error, like today. TSOperator (and function) overloading is not an OO feature. However, it's TSoften found in OO languages, and complements OO well. It's a different kind TSof polymorphism. It's no kind of polymorphism at all. Yes, overloading is a form of polymorphism. Depending on the type of the arguments, different functions are called. This is analogous to inheritance-based polymorphism (virtual functions). See http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.pdf for a good treatment of the various kinds of polymorphisms there are (even if the article is rather mathematical/technical). It just an infix form of writing a method instead of prefix form, with additional problem that it is confused with plain old arithmetics. I see no value at all in this except for cool toy value - which is not enough to add such a serious change in the language. I beg to differ. Operator overloading allows you to write what essentially are domain-specific languages (DSLs) in the language itself. For example Boost.Spirit allows you to write a
Re: [PHP-DEV] PHP 5.1
From: Jani Taskinen [EMAIL PROTECTED] On Thu, 3 Feb 2005, Terje Slettebø wrote: Why would it be ok there, but not in PHP? It also exists in other scripting languages, such as Python and Perl. PHP is not Perl or Python or add-your-favorite-language-here. That's not an argument against operator overloading. The question is why would it not be appropriate for PHP? Dynamic typing has been mentioned, and when I said that it exists in other dynamically typed languages, as well, I get the reply that PHP is not language xxx. What kind of reply is that?! Ilia Alshanetsky suggested in a posting that the PHP community in general might not be ready for its safe introduction (i.e. they would typically misuse it). I hope it's not the case; after all, it's not such an advanced feature, when several mainstream languages has it. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Jani Taskinen [EMAIL PROTECTED]
C++ is not PHP and the sooner you realize this the better it will be.
I do realise it. However, I don't accept that as an argument against things
like operator overloading, which is found in scripting languages comparable
to PHP.
Adding operator overloading will add yet another layer of magic that
will confuse users, who for the most part have demonstrated that they
are not ready for such features.
Judging from much of the PHP code I've seen, I'm sorry to say that you may
be right... However, that doesn't mean _no_ users are ready for it.
If anything it'll only over complicate
applications making them neigh impossible to debug and require all sorts
of hackery inside the language itself to support this functionality.
My experience isn't that misuse of language features is the biggest cause of
messy code, as inexperienced developers typically aren't aware of more
advanced features, and therefore don't use them. Rather, my experience is
that the biggest cause of messy code is simply lack of competence, beyond
knowing the language itself. Learning to be a good programmer takes many
years, regardless of language.
Those who are experienced enough to shoot themselves in the foot, but not
experienced enough to aim properly, :) might, however, obfuscate code with
misuse of more advanced language constructs (variable variables and
variable functions comes to mind), but that doesn't mean we should forbid
these features in the language!
Used properly, if anything, the features proposed in my postings (like
overloading, and optional type checking) would allow people to _simplify_
their code. C++ code is typically simpler than Java code, for this reason.
Take this example (incrementing an element in a map):
C++:
++my_map[key];
Java:
if ( !my_map.containsKey( key ) )
my_map.put( key, new Integer( 1 ) );
else
{
Integer count = ( Integer )my_map.get( key ) );
int icount = count.IntValue();
my_map.put( key, new Integer( ++icount ) );
}
Operator overloading isn't the only thing playing a part, here (the ability
to treat built-in and user-defined types the same way is another major
factor), but it's a major factor.
Now, for this particular example, PHP actually has a similarly succinct
form, but that's only because the PHP array _is_ a map, so you have a
built-in type with operators:
++$my_map[$key];
The advantage of operator overloading is similar to the advantage of
symbolic notation in mathematics: It allows you to succinctly express your
intent, and it's also international.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: George Schlossnagle [EMAIL PROTECTED] By the way, I have your book (Advanced PHP Programming), which I found very good. :) I've also recently got Andi Gutmans, Stig S. Bakken and Derick Rethans book, PHP 5 Power Programming, which, from what I've seen of it, also looks very good, and I'm looking forward to reading it. On Feb 3, 2005, at 1:58 PM, Terje Slettebø wrote: Hm, I'm surprised by this response from someone who's name I recognise as an active PHP contributor. The answer strikes me as either arrogant and/or ignorant (note: I'm not saying you are that, but that's how the reply comes across, given what what operator overloading is about). As I've pointed out in other postings in this thread, operator overloading is about much more than just syntactic sugar. In C++, for example, it enables important things such as function objects (being able to pass an object to a function, for example, and have it behave as a function, enabling functional programming, as well). This is not possible (possibly without jumping through major hoops) in PHP. That's because functions are not first-class objects in PHP. You can do this same thing in straight C without operator overloading. While I'm happy (for you) that you like operator overloading, the view that it is inherently evil and leads to obtuse, magical code is not relegated to us PHP luddites. These ideas have all been discussed in depth long before you appeared on the scene to decry our lack of interest in 'evolving' the language to your liking. Yes, I know that operator overloading, as well as statically typed/dynamically typed, type checking, etc. are hotly debated topics, and that can be healthy, at least as long as there are reasonable arguments for either side. What I decried wasn't this thing in particular, and I'm relatively new to the PHP online community, but from the responses I got, felt something of a complacency (The language is good enough as it is. Who needs advanced features. They may be misused. Etc.), and I guess I reacted to that, because I find it rather different in the C++ mailing lists and newsgroups, where there's often lively discussions about the evolution of the language. So it was more a perceived lack of willingness to consider, or reconsider, proposals, and give reasonable arguments in return. Arguments where given, I replied to them, and then it typically went nowhere from there. Anyway, I'd be interested in any evolution, and by all means, PHP 5 has come a long way. But it probably wouldn't have been like this, had there not been early adopters, and people pushing for things like better OO support. Let me also mentioned that I _have_ found cool things in PHP, especially things making it easier for web-programming, such as things like variable functions, where you may dispatch to a function based on a string, for example a GET parameter. This can lead to rather elegant code. Likewise, the OO support is quite good, now. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
From: Stanislav Malyshev [EMAIL PROTECTED]
TSWhen you say typeless, i think you mean not statically typed.
Not only, but in this case it is the main trait I meant.
...Because PHP has types, so I felt it was a misnomer to call it typeless.
TSthrough this discussion elsewhere - a variable will at any one time
have a
TSwell-defined type (or unset), which you may overload on, so the
language is
That's the whole point - in PHP there's no mechanism you could overload
function based on the types of their parameters, neither statically nor
dynamically. To add this thing would be a very major change and will open
galactic-size can of worms (think implicit conversions, converting
constructors, multiple inheritance, etc.).
No, you don't have to go that far. For starters, one could allow function
(and possibly operator) overloading, based on type hints. The following is
legal PHP5:
function something(SomeClass $value) { ... }
We could make the signature (currently only the name) extend to include the
parameters, as well, so we could allow the following, without errors about
duplicate definition:
function something(AnotherClass $value) { ... }
That's it. That's all you need for function overloading. You can safely keep
the lid on that can of worms of yours. :) If we were to extend this, I'm
sure we'd find a way to deal with any worms.
And this would seriously complicate function call logic
It would increase the complexity somewhat, since you have to perform
overload resolution. However, how much on an impact this would have on
execution speed remains to be seen.
- which is very bad, because, unlike
statically-typed language, we can not offload this complexity to one-time
compile stage.
Right.
TSYes, variables are dynamically typed, but when you call a function,
you
TStypically have an idea of what its type is. Otherwise, the type
hints for
TSPHP 5 would be pointless! By your argument.
Type hints check if the argument passed to function is of the right type.
They don't make PHP call different functions on different argument types.
I know. My point was that, as we have type hints, we have a way to
differentiate functions, since they may now both have variable types, and
number of parameters.
TS - except for select things like
TS complex and matrices (and maybe two more things like this) I don't
see any
TS value in having, say, + overloaded. Using good old methods will
never fail
TS you.
TS
TSNeither will assembly code.
What is with that assembly code that you keep mentioning it?
It was a reaction to the oft-mentioned argument that essentially says: We
don't need more advanced features. I got that feeling when you said Using
good old methods will never fail you.. However, I may have misread you. If
taken to the limit, you don't need more than ones and zeroes to program, but
it sure makes it easier to have higher levels of abstraction. Anyway, it
seems we agree on that.
Assembly code
is entirely irrelevant to the discussion, since, as I already explained
once, difference between assebmly code and higher-level programming
languages in in complexity incapsulation, while difference between
operator overloading and using method is purely syntactical - operator
overloading can be translated one-to-one to method calls without exposing
any complexity, while translating method call to assemly exposes a lot of
complexity.
I've replied to this in the reply to that posting, so I won't go into it
here.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Stanislav Malyshev [EMAIL PROTECTED] TSacross, given what what operator overloading is about). As I've pointed out TSin other postings in this thread, operator overloading is about much more TSthan just syntactic sugar. In C++, for example, it enables important I think you did not succeed in proving this point. You keep bringing examples of how useful it is in C++ - which can be interesting to debate, but is entirely irrelevant to PHP, since PHP is different from C++ on many levels and tasks that are solved with operators in C++ often even not exist in PHP (like smart pointers, etc.). I still fail to see how it can be really useful - in terms of making something that was very hard to do before easy to do now - beyond they syntax sugar value. It's a little hard to bring examples of PHP usage of it, since it doesn't exist there, and therefore we have no experience with it. However, I saw someone post a patch about it, enabling overloaded operators in PHP. TSthings such as function objects (being able to pass an object to a function, TSfor example, and have it behave as a function, enabling functional TSprogramming, as well). This is not possible (possibly without jumping TSthrough major hoops) in PHP. Surely it is. Via __call, for example, which is no worse than operator(). Yes, you could not write it the same syntax as C++ - so what? An advantage of function objects in C++ is that they can be used where functions are expected. Nevertheless, there are some features that can be used to get something similar, such as create_function(): TSHowever, I see from this and other threads, that there's not much chance of TSevolution of PHP to support more advanced features (which are common in There's a lot of chance for PHP to evolve, but if you mean by it that any feature that you might like would be in without scrutiny - yes, there's little chance for that. By all means, I'm all for scrutiny. :) That's why I bring it up, to possibly stimulate some discussion about it, and, yes, scrutiny. I may learn at least as much from this as anyone else. Simply put, I'd like to know what the arguments for and against are, so that, yes, they may be scrutinised. TSother scripting languages, as mentioned). It seems basic OO support is about TSthe only thing the PHP community can handle when it comes to expressiveness TSin the language. Oh, well. It means you probably won't see in PHP every feature that your favorite other language has. So what? Your favorite other language probably doesn't have all the features of PHP. The new features for PHP should be checked if they are good for PHP and can be implemented consistently and efficiently in PHP. True. I see what I wrote above was rather harsh. I guess I in a way hoped that someone would tell me I'm wrong. :) And that the PHP community _is_ interested in improvements in the language (any improvements, these are just some possibilities), and that possibly what I suggest is not what is found to be most interesting, but feature xyz may be, or library x. That would have been fine. I'm here to learn, too. So, ok, I acknowledge that the community _is_ interested in improvements in the language, and therefore take back the paragraph you quote above (and any statements like it). Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
From: Derick Rethans [EMAIL PROTECTED] Oh, hello. I recognise your name as one of the other authors of the book PHP 5 Power Programming, which I've recently got, and which looks very good. It seems like all the big guns are on this list. :) (similar to comp.lang.c++.moderated and comp.std.c++ for C++). On Thu, 3 Feb 2005, Stanislav Malyshev wrote: PJ$b-a++; gives tmp = a; tmp = tmp+1; b-a = tmp; PJ PJIn my example (a date object, day being 31), at this I do not know PJif one is assigning 32 to the property or if it's the result of PJincrementation (or decrementation from 1 to 0). nor manipulating properties directly :) I know you put a :) there, but if you really mean it then you should NOT be using PHP! Reason: PHP isn't about OO cosyness - it's about solving a Web problem. Hm, from several postings, I've detected something of a - I don't quite know how to say it in English - resentment against OO on PHP lists and newsgroups. Why is this? Unfamiliarity with it, or what? It typically gets expressed as derogatory expressions like cosyness or cuteness, as a quick and dirty attempt to discredit something without any proper argument. Now, whether or not you're accessing properties has nothing in particular with the language you use; it's a design issue. Oh, and it has nothing to do with cosyness and everything to do with program robustness, correctness, encapsulation, decoupling of interface from implementation, and other time-honoured software development principles (which are independent of any particular paradigm, such as OO). Most software development experts aren't religious about the issue of accessor functions. If your class is basically just a value container, without any class invariants to maintain, then accessing properties directly may be a reasonable way to do it. In the case of a date object, it's a really bad idea to be able to access the properties directly, because, as it says in the quote above, you may e.g. increment the day beyond the end of the month, setting it to a negative value, etc. In short, it's an error-prone and bad design. Since you think it's a good idea to _have_ public properties for date objects, I'd like to hear your reasons for it. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Derick Rethans [EMAIL PROTECTED] TSAs someone said, Syntactic sugar matters, or we'd all be TSwriting assembly code. :) Someone was wrong. There are syntax constructs that allow to reduce complexity of the code, and there are constructs that make the code have the same complexity but look prettier to the eyes of the writer. It depends on how you define complexity. Are the following two lines equally complex to you: Let me be blunt as you;'e not giving up. We will not add it. Period, punt, punktum. This discussion is pointless - stop it! Apparently it is, but not because I've got convincing arguments in return. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: David Zülke [EMAIL PROTECTED] No offense, but before even thinking about operator overloading support, really useful and crucial stuff like namespaces or Unicode support should be tackled first. None taken. :) Part of the reason for posting was to find out what people would like to have in the language/library. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Greg Beaver [EMAIL PROTECTED] Terje Slettebø wrote: 1) $result=$c1.multiply($c2).divide($c1.add($c2)); 2) $result=($c1 * $c2) / ($c1 + $c2); They sure aren't to me. Moreover, they are not the same: operator overloading enable you to use infix notation, whereas functions use prefix, only. Um, you're wrong. Infix is quite easy to do using (static or non-static) functions: 3) $result = Complex::divide(Complex::multiply($c1, $c2), Complex::add($c1, $c2)); Let me rewrite your expression as an abstract expression: result = op(op(c1, c2), op(c1, c2)) Here, op is the function name (add, etc.). As you can see, your expression is still one using prefix operators (op arg1 arg2), rather than infix (arg1 op arg2). I'm afraid your correction is incorrect. Your example is the same as 1), above, using static functions. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Christian Schneider [EMAIL PROTECTED] Terje Slettebø wrote: Those who are experienced enough to shoot themselves in the foot, but not experienced enough to aim properly, :) might, however, obfuscate code with misuse of more advanced language constructs (variable variables and variable functions comes to mind), but that doesn't mean we should forbid these features in the language! You're wrong We should forbid variable variables and variable functions? That's what I talked about when we said that doesn't mean we should forbid these features in the language. , that's exactly one of the things PHP does: Keep the language simple by limiting the amount of (syntactic) magic. Keeping a language simple is not necessary a good thing in itself. C is an example of a relatively simple language, for example. When we make applications, there's a certain amount of essential complexity, and that complexity has to go somewhere. When we have OO support, and libraries, we can delegate much of that complexity to the language/library, making our programs simpler. If the complexity is not in the language or library, it'll be in the programs. I'd rather have the complexity in the language or library, so that the programs can be simpler. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: Jani Taskinen [EMAIL PROTECTED] On Thu, 3 Feb 2005, Terje Slettebø wrote: From: Jani Taskinen [EMAIL PROTECTED] On Thu, 3 Feb 2005, Terje Slettebø wrote: Why would it be ok there, but not in PHP? It also exists in other scripting languages, such as Python and Perl. PHP is not Perl or Python or add-your-favorite-language-here. That's not an argument against operator overloading. The question is why would it not be appropriate for PHP? Dynamic typing has been mentioned, and when I said that it exists in other dynamically typed languages, as well, I get the reply that PHP is not language xxx. What kind of reply is that?! Quote from your mail: Why would it be ok there, but not in PHP? It also exists in other scripting languages, such as Python and Perl. Please explain me why it's okay for you to use the other-languages-card but not for me? :) Ok. The argument went something like this: I asked (although that was originally in another thread) about the possibility of getting operator overloading in PHP, and I presented reasons for why this may be useful. Then someone replied that PHP is dynamically typed, so it doesn't fit the language. I countered with that there are other languages that are also dynamically typed, but where they do have operator overloading. Now, if the doesn't fit the language argument should stick, one could need to either: 1) Explain why it's a bad idea in these other languages, as well, or: 2) Explain how PHP is different, and why it doesn't fit PHP, unlike these languages. Now, have I got any answers to this? No! All I've got (from your posting, anyway) is PHP is not language xxx. And? How does it change the argument? In what way is it different, so that operator overloading would not fit with PHP? I've got some answers in this thread, and I'll also search the archive for the rest, but PHP is not language xxx is a meaningless answer. My use of the other languages was to show that other languages find it useful. Your use of other languages... well, it only says that PHP are not them, which doesn't really say anything beyond the obvious. I'm sorry, but our two arguments can't be compared. Please, end this thread already and face the fact that this feature will not get into PHP 5.1. I have no illusions of it going into PHP 5.1... This wouldn't be appropriate for a point release, for one thing. I have also very little belief of it ever getting into PHP, judging from the discussion. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
From: George Schlossnagle [EMAIL PROTECTED] Yes, I know that operator overloading, as well as statically typed/dynamically typed, type checking, etc. are hotly debated topics, and that can be healthy, at least as long as there are reasonable arguments for either side. What I decried wasn't this thing in particular, and I'm relatively new to the PHP online community, but from the responses I got, felt something of a complacency (The language is good enough as it is. Who needs advanced features. They may be misused. Etc.), and I guess I reacted to that, because I find it rather different in the C++ mailing lists and newsgroups, where there's often lively discussions about the evolution of the language. The real problem is that there's a constant influx of (usually) well-meaning people like yourself who come to the lists to propose ideas which have been discussed in depth numerous times before and which have been discarded (for better or worse, my personal opinion is for better in this case). I figured that could be the case, which is also, in my first postings, I said that if this had been discussed before, I'd appreciate pointers to it, because I hadn't found it in the archive. However, I got hardly any response to that, which is why I kept asking about things that may have been asked and answered a zillion times. At any rate, it's been discussed before and shelved, long before you came on the scene. Even though the topic is new for you in this venue, it's old for many other people, and it gets annoying to rehash the same topics every couple months when someone new joins the list. The discussions are all in the archives though, if you want to see the less-reactionary roots of the rejections. I've searched for overloading on the archive for this list, as well as others and the newsgroups, but, as I said above, found very little about it. However, now that I know it's there, I'll make a new attempt. Thanks for your reply. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
From: Darrell Brogdon [EMAIL PROTECTED] I don't think its really a resentment (for the most part) against OO in PHP even if it seems that way. One of the stated goals of PHP is to have a low learning curve and this is something it does very well. I'm sure you can agree that OO concepts typically don't fit that criteria which is why you can still build complete PHP apps without using any OO concepts. Yes, the gentle learning curve of PHP, and that you don't have to use OO is a good thing. So the seemingly resentful attitudes should probably be viewed as one of lets do our best to keep this as simple as possible while retaining the power it is intended to provide. Ok. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
