Hi there,
Through its history, PHP has slowly become more object-oriented. PHP
today has classes, interfaces, objects, namespaces, and so on.
However, much of the language's core functionality is entirely
procedural, composed of functions and constants, much of which are
badly organised and inconsistently named.
I think PHP could benefit from making arrays, strings, integers,
floats, and possibly booleans, into "pseudo-objects". By this I mean
that they are not really objects (they are still primitive types and
keep their passing semantics), but they have methods. For instance,
instead of array_keys($array), one could do $array->keys();
Adding this would make PHP feel more modern and allow people to
embrace more object-oriented programming styles. As a bonus, it would
also give a chance to make the string/array/etc functions better and
more consistently named and possibly implemented.
I am working on an implementation of this for arrays, but I haven't
got very far. However, for someone that knows the Zend engine
internals, it does not appear to me that adding such things would be
very difficult.
Thoughts?
--
Andrew Faulds (AJF)
http://ajf.me/
On Tue, Jul 17, 2012 at 1:27 AM, Andrew Faulds ajfweb@googlemail.comwrote:
Hi there,
Through its history, PHP has slowly become more object-oriented. PHP
today has classes, interfaces, objects, namespaces, and so on.
However, much of the language's core functionality is entirely
procedural, composed of functions and constants, much of which are
badly organised and inconsistently named.I think PHP could benefit from making arrays, strings, integers,
floats, and possibly booleans, into "pseudo-objects". By this I mean
that they are not really objects (they are still primitive types and
keep their passing semantics), but they have methods. For instance,
instead of array_keys($array), one could do $array->keys();Adding this would make PHP feel more modern and allow people to
embrace more object-oriented programming styles. As a bonus, it would
also give a chance to make the string/array/etc functions better and
more consistently named and possibly implemented.I am working on an implementation of this for arrays, but I haven't
got very far. However, for someone that knows the Zend engine
internals, it does not appear to me that adding such things would be
very difficult.Thoughts?
we have that brought up once or twice in the past, last time it was Rasmus
who mentioned that it could be nice:
http://marc.info/?l=php-internals&m=130159506720600&w=2
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Through its history, PHP has slowly become more object-oriented.
While PHP has become more capable for OOP, it has also become more
capable for FP, too. And, procedural programming is still a very
strong influence.
I think PHP could benefit from making arrays, strings, integers,
floats, and possibly booleans, into "pseudo-objects". By this I mean
that they are not really objects (they are still primitive types and
keep their passing semantics), but they have methods. For instance,
instead of array_keys($array), one could do $array->keys();
If the pseudo objects keep their passing semantics, this could be a
source of confusion.
Adding this would make PHP feel more modern and allow people to
embrace more object-oriented programming styles. As a bonus, it would
also give a chance to make the string/array/etc functions better and
more consistently named and possibly implemented.
I'm not sure I would classify it as more modern or if we should be
hoping more people embrace OOP. The language would feel more OO with
these changes, but there are many programming paradigms that are are
trending now (FP, AOP, DbC, homoiconic languages like Clojure, Lisp,
and Julia have helped promote meta-programming, etc.) I like that fact
that PHP falls back into a procedural paradigm nicely, whilst still
allowing me to use OOP design patterns and FP techniques for the bulk
of my applications.
While I'd like to see more consistency within the core functions, I'm
not sure this is the route to take.
Adam
Em Tue, 17 Jul 2012 01:27:10 +0200, Andrew Faulds ajfweb@googlemail.com
escreveu:
Through its history, PHP has slowly become more object-oriented. PHP
today has classes, interfaces, objects, namespaces, and so on.
However, much of the language's core functionality is entirely
procedural, composed of functions and constants, much of which are
badly organised and inconsistently named.I think PHP could benefit from making arrays, strings, integers,
floats, and possibly booleans, into "pseudo-objects". By this I mean
that they are not really objects (they are still primitive types and
keep their passing semantics), but they have methods. For instance,
instead of array_keys($array), one could do $array->keys();Adding this would make PHP feel more modern and allow people to
embrace more object-oriented programming styles. As a bonus, it would
also give a chance to make the string/array/etc functions better and
more consistently named and possibly implemented.
As I said in IRC, I have some reservations about this.
Let's ignore empty arguments like "make[s] PHP feel modern". That aside,
the main argument advanced in this message makes no sense. Adding method
call syntax to arrays hardly makes PHP more object oriented. Syntax is
unimportant. There's no substantial difference between array_slice($arr,
...) and $arr->slice(...). Object orientation is about polymorphism,
encapsulation, inheritance, etc. None of that is advanced by the proposed
change. And even if it was, you would still have to justify why that would
be a positive development.
Plus, it's very odd to claim this would make PHP more object oriented when
there are no objects involved! I don't think it's necessary to enumerate
all the differences between objects and arrays -- one that would be
particularly confusing would be the different passing semantics (or more
accurately, different levels of indirection).
There is, in my opinion, one merit here -- redesigning -- and perhaps
reimplementing -- the arrays functions API. This will require a lot of
work, thought, and time tough.
--
Gustavo Lopes
hi,
Let's ignore empty arguments like "make[s] PHP feel modern". That aside, the
main argument advanced in this message makes no sense.
This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.
The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.
Adding method call
syntax to arrays hardly makes PHP more object oriented. Syntax is
unimportant. There's no substantial difference between array_slice($arr,
...) and $arr->slice(...).
There is a huge difference. One of the main difference would be to
finally have an uniform API and not this painful inconsistent APIs we
have to maintain.
There is, in my opinion, one merit here -- redesigning -- and perhaps
reimplementing -- the arrays functions API. This will require a lot of work,
thought, and time tough.
Yes, but long due, same for strings.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I think strings are even more important, they have an even messier API than
arrays.
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glopes@nebm.ist.utl.pt
wrote:Let's ignore empty arguments like "make[s] PHP feel modern". That aside,
the
main argument advanced in this message makes no sense.This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.Adding method call
syntax to arrays hardly makes PHP more object oriented. Syntax is
unimportant. There's no substantial difference between array_slice($arr,
...) and $arr->slice(...).There is a huge difference. One of the main difference would be to
finally have an uniform API and not this painful inconsistent APIs we
have to maintain.There is, in my opinion, one merit here -- redesigning -- and perhaps
reimplementing -- the arrays functions API. This will require a lot of
work,
thought, and time tough.Yes, but long due, same for strings.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes
glopes@nebm.ist.utl.pt wrote:Adding method call
syntax to arrays hardly makes PHP more object oriented. Syntax is
unimportant. There's no substantial difference between
array_slice($arr,
...) and $arr->slice(...).There is a huge difference. One of the main difference would be to
finally have an uniform API and not this painful inconsistent APIs we
have to maintain.
There isn't a difference in terms of making PHP more object oriented,
which was the main advantage advanced by the OP. I'm all for redesigning
strings/arrays APIs (presented as an afterthought by the OP), but for
that the discussion should be centered on what those APIs will look
like, not the syntax one uses to call them.
In fact, quite frequently, syntax discussions make more important
design decisions be ignored (see namespaces).
There is, in my opinion, one merit here -- redesigning -- and
perhaps
reimplementing -- the arrays functions API. This will require a lot
of work,
thought, and time tough.Yes, but long due, same for strings.
--
Gustavo Lopes
hi Gustavo,
There isn't a difference in terms of making PHP more object oriented, which
was the main advantage advanced by the OP. I'm all for redesigning
strings/arrays APIs (presented as an afterthought by the OP), but for that
the discussion should be centered on what those APIs will look like, not the
syntax one uses to call them.
To provide pseudo objects is a damned good point and long due. Please
don't focus on a badly formulated initial post (more object oriented),
we are not in a CS course but in the PHP internals discussions list
:).
In fact, quite frequently, syntax discussions make more important design
decisions be ignored (see namespaces).
Syntax easiness and APIs cleanness are what make a language attractive.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I might not have made it clear, but the main reasons I want it are:
- Chance to clean up array/string/etc APIs
- Looks nicer IMO, slightly clearer what functions do and affect
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes
glopes@nebm.ist.utl.pt wrote:
Adding method call
syntax to arrays hardly makes PHP more object oriented. Syntax is
unimportant. There's no substantial difference between array_slice($arr,
...) and $arr->slice(...).There is a huge difference. One of the main difference would be to
finally have an uniform API and not this painful inconsistent APIs we
have to maintain.There isn't a difference in terms of making PHP more object oriented,
which was the main advantage advanced by the OP. I'm all for redesigning
strings/arrays APIs (presented as an afterthought by the OP), but for that
the discussion should be centered on what those APIs will look like, not
the syntax one uses to call them.In fact, quite frequently, syntax discussions make more important design
decisions be ignored (see namespaces).There is, in my opinion, one merit here -- redesigning -- and perhaps
reimplementing -- the arrays functions API. This will require a lot of
work,
thought, and time tough.Yes, but long due, same for strings.
--
Gustavo Lopes
Pierre Joye wrote:
This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.
Probably a silly question, but what popped into my mind was the way C++ was
supposed to enhance C by adding these sort of rich functions in extra libraries.
As a stepping stone, couldn't the mbstring package be re-factored as an OO
library and used as a testbed for a new strings API? I would assume that this
would all be natively multibyte aware from day one and I can't think of anything
that is missing from mbstring?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
hi,
Let's ignore empty arguments like "make[s] PHP feel modern". That aside, the
main argument advanced in this message makes no sense.This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.
And also because most of the proposals are simply strong-typing in
disguise. If you turn scalars into objects and attach methods to those
objects are you still going to be able to call floor() on a numeric
string? This isn't as simple as people think on first glance and it
doesn't really clean up the global namespace since we still need to be
able to do type coercion which effectly implies that all scalar objects
need to include the bulk of the current set of scalar functions.
-Rasmus
Whilst weak typing has its benefits, I think typing is a little too weak in
places. IMO "" should not be equal to 0 or coercable to 0. But of course
"0" should equal 0.
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glopes@nebm.ist.utl.pt
wrote:Let's ignore empty arguments like "make[s] PHP feel modern". That
aside, the
main argument advanced in this message makes no sense.This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.And also because most of the proposals are simply strong-typing in
disguise. If you turn scalars into objects and attach methods to those
objects are you still going to be able to callfloor()on a numeric
string? This isn't as simple as people think on first glance and it
doesn't really clean up the global namespace since we still need to be
able to do type coercion which effectly implies that all scalar objects
need to include the bulk of the current set of scalar functions.-Rasmus
Whilst weak typing has its benefits, I think typing is a little too weak
in places. IMO "" should not be equal to 0 or coercable to 0. But of
course "0" should equal 0.
Which has nothing to do with this thread.
On Jul 17, 2012 3:04 PM, "Rasmus Lerdorf" <rasmus@lerdorf.com
mailto:rasmus@lerdorf.com> wrote:> hi, > > On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt <mailto:glopes@nebm.ist.utl.pt>> wrote: > >> Let's ignore empty arguments like "make[s] PHP feel modern". That aside, the >> main argument advanced in this message makes no sense. > > This idea has been proposed many times in the past and it is actually > a very good proposal, for array, string or other types. > > The only reason why it is not yet implemented is the technical > complexity to do it. We need pseudo objects and the likes, and it is > really not something easy to do, in an efficient enough way. And also because most of the proposals are simply strong-typing in disguise. If you turn scalars into objects and attach methods to those objects are you still going to be able to call `floor()` on a numeric string? This isn't as simple as people think on first glance and it doesn't really clean up the global namespace since we still need to be able to do type coercion which effectly implies that all scalar objects need to include the bulk of the current set of scalar functions. -Rasmus
Hi!
This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.
If we have "$array->foo()", we should also have "class foo extends
array" which allows to override foo() in array. This will require some
serious changes, which need to be RFCed and reviewed and seen if they
can really fit the language properly. Just saying "let's bolt on method
calls on top of arrays" is definitely not very good. Having OO Array
type may be good, if we will be able to figure out suitable design that
will allow the same flexibility and power as regular arrays - though I'm
not sure how to do it now.
The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.
I disagree - I do not think we need pseudo-objects. If the only point of
the exercise is to convert a call of array_pop to $array->pop, it's not
worth it. It'd just make the language more messy - you wouldn't know
what -> means anymore.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.If we have "$array->foo()", we should also have "class foo extends
array" which allows to override foo() in array. This will require some
serious changes, which need to be RFCed and reviewed and seen if they
can really fit the language properly. Just saying "let's bolt on method
calls on top of arrays" is definitely not very good. Having OO Array
type may be good, if we will be able to figure out suitable design that
will allow the same flexibility and power as regular arrays - though I'm
not sure how to do it now.The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.I disagree - I do not think we need pseudo-objects. If the only point of
the exercise is to convert a call of array_pop to $array->pop, it's not
worth it. It'd just make the language more messy - you wouldn't know
what -> means anymore.
+1
I am for making array a proper class with methods.
"Legacy" functions can be implemented as wrappers around it:
function array_push(&$array, $value)
{
$array->push($value);
}
There is absolutely no sense in creating new "pseudo object" entity. It would just add tons of confusion.
p.s. in case of array, we already have http://docs.php.net/ArrayObject which is a good starting point
Hi!
I am for making array a proper class with methods.
"Legacy" functions can be implemented as wrappers around it:
function array_push(&$array, $value) { $array->push($value); }
The problem there is that array has different semantics than object. Not
completely, but for example if you pass array to function, it is passed
by value and is not modified, but objects are always mutable when passed
to functions. Changing this semantics will break a lot of code.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I am for making array a proper class with methods.
"Legacy" functions can be implemented as wrappers around it:
function array_push(&$array, $value)
{
$array->push($value);
}The problem there is that array has different semantics than object. Not
completely, but for example if you pass array to function, it is passed
by value and is not modified, but objects are always mutable when passed
to functions. Changing this semantics will break a lot of code.
Having special handling of Array objects doesn't sound good too. And I don't see any nice solution.
Options are:
- "5-to-6" tool, similar to python's "2-to-3" converter, which will fix code.
- introduce some kind of per-file declare() option, which would enable pass-by-reference semantics of arrays/strings/etc. in 5.5 which would let people write the same code for 5.5 and 6.x
Well, actually, there's one more option: we can introduce "Autocloned" interface (empty, without methods) and force "cloning" of objects, which implement this interface, during parameter-fetching phase.
This would allow us to have 2 sets of classes: One set which implements this interface (slower, but backwards-compatible) and another set which doesn't (faster, but not compatible).
Hi!
Options are: * "5-to-6" tool, similar to python's "2-to-3" converter,
which will fix code.
Do you know any practical way of how such tool could work?
- introduce some kind of per-file declare() option, which would
enable pass-by-reference semantics of arrays/strings/etc. in 5.5
which would let people write the same code for 5.5 and 6.x
I don't think it's a viable option. The goal is to run existing code, if
you'd need to change each file that defeats the purpose of it.
Well, actually, there's one more option: we can introduce
"Autocloned" interface (empty, without methods) and force "cloning"
of objects, which implement this interface, during parameter-fetching
phase. This would allow us to have 2 sets of classes: One set which
It's not only parameter fetching. It's everywhere - assignment, access,
etc. Example:
$b = $a;
$b[0] = 1;
$a should not change in this situation, for arrays. For objects, $a and
$b are the same. Different semantics. Introducing such semantics for
classes would be a major complication in the engine, even if it's doable
(which I doubt) I don't think it is a goo idea.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Options are: * "5-to-6" tool, similar to python's "2-to-3" converter,
which will fix code.Do you know any practical way of how such tool could work?
That would be: tokenizer + static analysis (with type inference) + replacing some of the tokens.
Not a trivial task, but definitely doable.
And a large amount of php code (popular tools, frameworks, …) for writing tests :)
Hi!
That would be: tokenizer + static analysis (with type inference) + replacing some of the tokens.
Not a trivial task, but definitely doable.
So what would this tool do with this code?
$a = getFirstArrayName();
$b = getSecondArrayName();
$$a = $$b;
$b[1] = 0;
Or this:
include 'a.inc';
$a = $b;
include 'b.inc';
where a.inc has array $a and b.inc has something like $b[1] = 0; but you
have no way of knowing it since by the time you run the tool a.inc and
b.inc are not available to it (think config files).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
That would be: tokenizer + static analysis (with type inference) + replacing some of the tokens.
Not a trivial task, but definitely doable.So what would this tool do with this code?
$a = getFirstArrayName();
$b = getSecondArrayName();
$$a = $$b;
$b[1] = 0;
Something like this:
$a = getFirstArrayName();
$b = getSecondArrayName();
if ($$b instanceof ArrayObject) {
$$a = clone $$b;
} else {
$$a = $$b;
}
$b[1] = 0;
Or this:
include 'a.inc';
$a = $b;
include 'b.inc';where a.inc has array $a and b.inc has something like $b[1] = 0; but you
have no way of knowing it since by the time you run the tool a.inc and
b.inc are not available to it (think config files).
well, the same as above. not pretty, but that's a safe fallback when type inference is not available.
hi,
I disagree - I do not think we need pseudo-objects. If the only point of
the exercise is to convert a call of array_pop to $array->pop, it's not
worth it. It'd just make the language more messy - you wouldn't know
what -> means anymore.
pseudo object for the reasons Rasmus mentioned in his previous post.
Having pure object would be not efficient enough and brings its lot of
caveats. Also it is important to keep in mind that this idea does not
apply only to array but to other types as well.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
Having pure object would be not efficient enough and brings its lot of
caveats. Also it is important to keep in mind that this idea does not
apply only to array but to other types as well.
Same for other types. Just adding -> doesn't make the code
object-oriented. And just bolting -> on top of regular function calls
because it looks prettier seems meaningless to me. OK, we could make
$foo->bar() mean bar($foo) - python already has pretty much the same
idea, after all - but what's the point in it? I don't see any that would
be worth the effort.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi!
Hi!
Having pure object would be not efficient enough and brings its lot of
caveats. Also it is important to keep in mind that this idea does not
apply only to array but to other types as well.Same for other types. Just adding -> doesn't make the code
object-oriented.
Not the point.
And just bolting -> on top of regular function calls
because it looks prettier seems meaningless to me. OK, we could make
$foo->bar() mean bar($foo) - python already has pretty much the same
idea, after all - but what's the point in it? I don't see any that would
be worth the effort.
See the other answers, clear APIs, no more argument mess, cleanness.
Those are pretty good selling points and without any kind of BC.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects. You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your APIs
clean. Using -> has absolutely nothing to do with API cleanness and
arguments, so I don't understand how it's an argument for pseudo-objects.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your APIs
clean.
I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
The reasons why it is not yet implemented have been listed here, only
a matter of time :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
I'm sorry, but I can't understand how we can seriously consider making
object call syntax mean two entirely different things, create
pseudo-objects that look like objects in some situations, but not other
situation and generally make a huge mess out of whole object model -
because "-> is sexy". Is this really a level we want to have in the
discussion?
And no, it does not "allow us to clean our APIs" - I again point out
using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
as if it is some magic spell will not make false statement true, and the
statement that using -> somehow cleans up APIs is false. Cleaning APIs
and pseudo-objects are two completely different things, and nobody yet
shown any relationship between the two.
The reasons why it is not yet implemented have been listed here, only
a matter of time :)
IMHO the reason it's not implemented is because it makes very little
sense, and only reason I've seen so far to do it is "because it's sexy".
Come on.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
And no, it does not "allow us to clean our APIs" - I again point out
using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
as if it is some magic spell will not make false statement true, and the
statement that using -> somehow cleans up APIs is false. Cleaning APIs
and pseudo-objects are two completely different things, and nobody yet
shown any relationship between the two.
You do not see it, your call. But it indeed does and anyone I was
talking to about this topic agrees with this view but two persons (you
incl.).
Anyway, it is somehow pointless to argue to death about that as it is
technically not possible yet. I'm 200% sure it will happen.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
OK, ok. Let me clear some things up here.
We don't want it to make things more object-oriented or whatever. The real
motivation is to give us a chance to make a much cleaner, much nicer array
API without breaking BC. We can keep the legacy array_* and unprefixed
functions, but we can also create "pseudo-object methods" (not objects, but
methods and possibly properties hooked into the method call processing,
checking for non-object types - it's very easy to check (I've done it) for
non-objects, and implementing this seems simple enough but I don't know the
Zend engine well enough). This way we can have array->key,
array->sort(TYPE), etc. for new code to use, instead of the legacy array
and string method mess (the latter needs a cleanup more in particular).
OK?
hi,
On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:And no, it does not "allow us to clean our APIs" - I again point out
using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
as if it is some magic spell will not make false statement true, and the
statement that using -> somehow cleans up APIs is false. Cleaning APIs
and pseudo-objects are two completely different things, and nobody yet
shown any relationship between the two.You do not see it, your call. But it indeed does and anyone I was
talking to about this topic agrees with this view but two persons (you
incl.).Anyway, it is somehow pointless to argue to death about that as it is
technically not possible yet. I'm 200% sure it will happen.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Seems a lot like another syntactic sugar.
Like in Lua, where you can write
obj:method(12)
instead of
obj.method(obj, 12)
But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing array?) is a tough one.
2012/7/18 Andrew Faulds ajfweb@googlemail.com
OK, ok. Let me clear some things up here.
We don't want it to make things more object-oriented or whatever. The real
motivation is to give us a chance to make a much cleaner, much nicer array
API without breaking BC. We can keep the legacy array_* and unprefixed
functions, but we can also create "pseudo-object methods" (not objects, but
methods and possibly properties hooked into the method call processing,
checking for non-object types - it's very easy to check (I've done it) for
non-objects, and implementing this seems simple enough but I don't know the
Zend engine well enough). This way we can have array->key,
array->sort(TYPE), etc. for new code to use, instead of the legacy array
and string method mess (the latter needs a cleanup more in particular).OK?
hi,
On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:And no, it does not "allow us to clean our APIs" - I again point out
using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
as if it is some magic spell will not make false statement true, and
the
statement that using -> somehow cleans up APIs is false. Cleaning APIs
and pseudo-objects are two completely different things, and nobody yet
shown any relationship between the two.You do not see it, your call. But it indeed does and anyone I was
talking to about this topic agrees with this view but two persons (you
incl.).Anyway, it is somehow pointless to argue to death about that as it is
technically not possible yet. I'm 200% sure it will happen.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
It would probably be passed as first param to functions, or passed as
$this, like other methods.
Seems a lot like another syntactic sugar.
Like in Lua, where you can write
obj:method(12)
instead of
obj.method(obj, 12)But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing array?) is a tough one.2012/7/18 Andrew Faulds ajfweb@googlemail.com
OK, ok. Let me clear some things up here.
We don't want it to make things more object-oriented or whatever. The real
motivation is to give us a chance to make a much cleaner, much nicer array
API without breaking BC. We can keep the legacy array_* and unprefixed
functions, but we can also create "pseudo-object methods" (not objects,
but
methods and possibly properties hooked into the method call processing,
checking for non-object types - it's very easy to check (I've done it) for
non-objects, and implementing this seems simple enough but I don't know
the
Zend engine well enough). This way we can have array->key,
array->sort(TYPE), etc. for new code to use, instead of the legacy array
and string method mess (the latter needs a cleanup more in particular).OK?
hi,
On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:
And no, it does not "allow us to clean our APIs" - I again point out
using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
as if it is some magic spell will not make false statement true, and
the
statement that using -> somehow cleans up APIs is false. Cleaning APIs
and pseudo-objects are two completely different things, and nobody yet
shown any relationship between the two.You do not see it, your call. But it indeed does and anyone I was
talking to about this topic agrees with this view but two persons (you
incl.).Anyway, it is somehow pointless to argue to death about that as it is
technically not possible yet. I'm 200% sure it will happen.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing array?) is a tough one.
For the user's point of view there is no difference between the passing
semantics of numbers/string primitives and objects. Only arrays differ.
However we already have ArrayAccess and so on for objects, which creates
array-like objects with object passing semantics. So the idea that something
that looks like array will have passing semantics like an array is already
wrong in PHP. The clarity of passing semantics is not a valid argument
against pseudo methods for string/int/float/array primitives.
Stan
Hi!
enough but I don't know the Zend engine well enough). This way we can
have array->key, array->sort(TYPE), etc. for new code to use, instead of
the legacy array and string method mess (the latter needs a cleanup more
in particular).
The mess does not exist because we have array_key() instead of
array->key(). There's nothing wrong with having array_key(). The mess
exists because functions do not form single API with single principle
behind it, but were added in ad-hoc manner, sometimes without
correlating them with others. So, if you want to clean it up, you'd want
to write a plan how new API would look like and how it will be better
than old one. If the solution is "let's use ->" then it's not worth it.
The solution that's worth it is "let's have this better API" and that's
where we should start, not with changing array_key() to array->key() and
saying "now we have clean sexy API".
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi Stas,
Hi!
enough but I don't know the Zend engine well enough). This way we can
have array->key, array->sort(TYPE), etc. for new code to use, instead of
the legacy array and string method mess (the latter needs a cleanup more
in particular).The mess does not exist because we have array_key() instead of
array->key(). There's nothing wrong with having array_key(). The mess
exists because functions do not form single API with single principle
behind it, but were added in ad-hoc manner, sometimes without
correlating them with others. So, if you want to clean it up, you'd want
to write a plan how new API would look like and how it will be better
than old one. If the solution is "let's use ->" then it's not worth it.
The solution that's worth it is "let's have this better API" and that's
where we should start, not with changing array_key() to array->key() and
saying "now we have clean sexy API".
Please let me refresh the psat years history of PHP releases. Any
attempt to change any kind of function signatures in the core has been
rejected for obvious reasons (BC breaks, useless code changes, etc.
etc.). So I won't spend a single second to try to propose to rewamp or
duplicate functions for the sake of making the signature more
consistent with each other, or cleaner.
On the hand, this solution allows that, right away, without BC breaks
and brings us to the (very) long term goal (actual object for standard
types, like in other languages).
Now you can totally disregard the benefit of this (purely vaporware
right now) solution, but to keep saying that this argument is
pointless is not going to bring us any step further, really not.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
WHAT?
Er, sorry, accidental capslock. This IS a new API. That was an example. I'm
not saying just put -> everywhere, I'm saying we can keep array_* and add a
new set of -> functions which are well-designed, consistent, etc.
Hi!
enough but I don't know the Zend engine well enough). This way we can
have array->key, array->sort(TYPE), etc. for new code to use, instead of
the legacy array and string method mess (the latter needs a cleanup more
in particular).The mess does not exist because we have array_key() instead of
array->key(). There's nothing wrong with having array_key(). The mess
exists because functions do not form single API with single principle
behind it, but were added in ad-hoc manner, sometimes without
correlating them with others. So, if you want to clean it up, you'd want
to write a plan how new API would look like and how it will be better
than old one. If the solution is "let's use ->" then it's not worth it.
The solution that's worth it is "let's have this better API" and that's
where we should start, not with changing array_key() to array->key() and
saying "now we have clean sexy API".--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Er, sorry, accidental capslock. This IS a new API. That was an example.
I'm not saying just put -> everywhere, I'm saying we can keep array_*
and add a new set of -> functions which are well-designed, consistent, etc.
What "this"? So far I didn't see any single message discussing anything
about any API. All I see is discussing how we should have -> syntax
working on arrays and strings. IMO this is exactly the wrong place to
start, if your goal is to improve the API (if your goal is to have
"sexy" syntax, it's fine but then I do not see this goal as worthy). The
right place to start would be the API.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Obviously. This is simply the means to provide the new API without breaking
BC. If people think this is acceptable then sure, let's plan an API.
Hi!
Er, sorry, accidental capslock. This IS a new API. That was an example.
I'm not saying just put -> everywhere, I'm saying we can keep array_*
and add a new set of -> functions which are well-designed, consistent,
etc.What "this"? So far I didn't see any single message discussing anything
about any API. All I see is discussing how we should have -> syntax
working on arrays and strings. IMO this is exactly the wrong place to
start, if your goal is to improve the API (if your goal is to have
"sexy" syntax, it's fine but then I do not see this goal as worthy). The
right place to start would be the API.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2012.07.18. 18:55, "Stas Malyshev" smalyshev@sugarcrm.com ezt írta:
Hi!
Er, sorry, accidental capslock. This IS a new API. That was an example.
I'm not saying just put -> everywhere, I'm saying we can keep array_*
and add a new set of -> functions which are well-designed, consistent,
etc.What "this"? So far I didn't see any single message discussing anything
about any API. All I see is discussing how we should have -> syntax
working on arrays and strings. IMO this is exactly the wrong place to
start, if your goal is to improve the API (if your goal is to have
"sexy" syntax, it's fine but then I do not see this goal as worthy). The
right place to start would be the API.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
Maybe we could introduce a new namespace for the new api instead of turning
the new api oop only (or using objects for groupping static stateless
functions into objects only to hint that they are working with the same
variable types).
Combining this with the previously mentioned lets turn namespaces to first
class citizens and allowing exporting whole namespaces to the current scope
would make it possible to make the new api available in the global scope if
needed.
Ofc this still would be a huge task to rethink/reshape our current api.
hi,
Maybe we could introduce a new namespace for the new api instead of turning
the new api oop only (or using objects for groupping static stateless
functions into objects only to hint that they are working with the same
variable types).Combining this with the previously mentioned lets turn namespaces to first
class citizens and allowing exporting whole namespaces to the current scope
would make it possible to make the new api available in the global scope if
needed.
Ofc this still would be a huge task to rethink/reshape our current api.
This falls almost exactly to what I would avoid to do, having same set
of functions but with new names or signatures, under a separate
namespace.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Stas Malyshev wrote:
I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
I'm sorry, but I can't understand how we can seriously consider making
object call syntax mean two entirely different things, create
pseudo-objects that look like objects in some situations, but not other
situation and generally make a huge mess out of whole object model -
because "-> is sexy". Is this really a level we want to have in the
discussion?And no, it does not "allow us to clean our APIs" - I again point out
using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
as if it is some magic spell will not make false statement true, and the
statement that using -> somehow cleans up APIs is false. Cleaning APIs
and pseudo-objects are two completely different things, and nobody yet
shown any relationship between the two.The reasons why it is not yet implemented have been listed here, only
a matter of time:)
IMHO the reason it's not implemented is because it makes very little
sense, and only reason I've seen so far to do it is "because it's sexy".
Come on.
Seconded ...
ArrayObject class is available if you want the 'sexy' way of doing things but
that adds nothing of use to the debate? My suggestion that the same is done for
mbstring seems to have fallen on deaf ears, but both of these would answer some
of the requests without affecting the core?
The current debate seems to be one of 'php is crap lets rewrite all of it', but
how much of the worlds online infrastructure is currently running using PHP and
in a lot of cases PHP4? We have compiled forks with different syntaxes if people
want to go that way, and yes we can stay with old versions, but we need reliable
security maintenance on some legacy base.
Please can we keep a 'legacy' version of PHP stable at some point in time ...
And let SonofPHP be forked off if that is what people want.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
hi,
Please can we keep a 'legacy' version of PHP stable at some point in time
... And let SonofPHP be forked off if that is what people want.
Totally off topic, and as stated earlier, this solution does not break
any existing functions or features.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your APIs
clean.I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:
$a = -5;
$b = "-5";
echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5
What has been cleaned here over:
echo abs($a);
echo abs($b);
other than being 2 characters longer to type? It's not like you can
remove abs() from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?
I think there is something we can do around this, but an argument of "it
is sexy and clean" needs to be backed up with some actual implementation
details that make sense.
-Rasmus
hi,
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your APIs
clean.
I really do not want to have a semantic discussion here.This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:$a = -5;
$b = "-5";echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5What has been cleaned here over:
echo abs($a);
echo abs($b);other than being 2 characters longer to type? It's not like you can
removeabs()from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?I think there is something we can do around this, but an argument of "it
is sexy and clean" needs to be backed up with some actual implementation
details that make sense.-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);
vs
$pos = $string->pos('a');
$pos = 'a'->pos($string);
I'm not proposing to use pos() as the method name, just showing an
example that this syntax can be cleaner.
David
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalyshev@sugarcrm.com wrote:Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your
APIs
clean.
I really do not want to have a semantic discussion here.This syntax is sexy, allows us to clean our APIs, and is amazingly
handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:$a = -5;
$b = "-5";echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5What has been cleaned here over:
echo abs($a);
echo abs($b);other than being 2 characters longer to type? It's not like you can
removeabs()from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?I think there is something we can do around this, but an argument of "it
is sexy and clean" needs to be backed up with some actual implementation
details that make sense.-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);vs
$pos = $string->pos('a');
$pos = 'a'->pos($string);I'm not proposing to use
pos()as the method name, just showing an
example that this syntax can be cleaner.
Or you could simply remember that it is always haystack,needle for
strings and needle,haystack for arrays. Not that complicated.
-Rasmus
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalyshev@sugarcrm.com wrote:Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your
APIs
clean.
I really do not want to have a semantic discussion here.This syntax is sexy, allows us to clean our APIs, and is amazingly
handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:$a = -5;
$b = "-5";echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5What has been cleaned here over:
echo abs($a);
echo abs($b);other than being 2 characters longer to type? It's not like you can
removeabs()from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?I think there is something we can do around this, but an argument of "it
is sexy and clean" needs to be backed up with some actual implementation
details that make sense.-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);vs
$pos = $string->pos('a');
$pos = 'a'->pos($string);I'm not proposing to use
pos()as the method name, just showing an
example that this syntax can be cleaner.Or you could simply remember that it is always haystack,needle for
strings and needle,haystack for arrays. Not that complicated.-Rasmus
Really? Good to know . . .
Right, because I've never got them the wrong way round, that is completely
logical, and this syntax makes it much harder.
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalyshev@sugarcrm.com wrote:Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your
APIs
clean.
I really do not want to have a semantic discussion here.This syntax is sexy, allows us to clean our APIs, and is amazingly
handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:$a = -5;
$b = "-5";echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5What has been cleaned here over:
echo abs($a);
echo abs($b);other than being 2 characters longer to type? It's not like you can
removeabs()from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?I think there is something we can do around this, but an argument of "it
is sexy and clean" needs to be backed up with some actual implementation
details that make sense.-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);vs
$pos = $string->pos('a');
$pos = 'a'->pos($string);I'm not proposing to use
pos()as the method name, just showing an
example that this syntax can be cleaner.Or you could simply remember that it is always haystack,needle for
strings and needle,haystack for arrays. Not that complicated.-Rasmus
hi Rasmus,
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:$a = -5;
$b = "-5";echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5What has been cleaned here over:
echo abs($a);
echo abs($b);
Heh, here is another example where it makes even less sense: time();
sigh.
More seriously... we are not talking about these APIs and I am sure
you know which one I refer to, like the string API and the like.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi Rasmus,
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:$a = -5;
$b = "-5";echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5What has been cleaned here over:
echo abs($a);
echo abs($b);Heh, here is another example where it makes even less sense:
time();sigh.
More seriously... we are not talking about these APIs and I am sure
you know which one I refer to, like the string API and the like.
Ok, so for the string API:
$a = 1;
$a->strstr('1');
should still work. All the string API methods need to be available on
every pseudo-object regardless of the type. So I don't see any "cleanup"
here either.
-Rasmus
should still work. All the string API methods need to be available on
every pseudo-object regardless of the type. So I don't see any "cleanup"
here either.
I do, and again this is purely a theoretical discussion right now.
However I find disturbing the resistance to such a proposal given that
what I hear from our users is a total support to introduce this
concept to PHP, even step by step.
So we should better begin to see where are the technical bottlenecks
and figure out a way to solve them instead of arguing about whether we
should do it or not. Because we will have to do it, whether we like it
or not.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
should still work. All the string API methods need to be available on
every pseudo-object regardless of the type. So I don't see any "cleanup"
here either.
I do, and again this is purely a theoretical discussion right now.
However I find disturbing the resistance to such a proposal given that
what I hear from our users is a total support to introduce this
concept to PHP, even step by step.So we should better begin to see where are the technical bottlenecks
and figure out a way to solve them instead of arguing about whether we
should do it or not. Because we will have to do it, whether we like it
or not.
So a few people want this therefore we all have to have it?
We need to sort out a list of priorities and then perhaps see if there is a
majority demand for each?
Since somebody will obviously rewrite key libraries using this 'sexy' stuff, we
are all then forced to have to work with it even if we can ignore it in our own
code. ONE of these days I'd like to get back to putting some new functions in my
own code base. I'm still working on a long list of 'strict' warnings across
several projects and libraries :( Work that I don't make any money from but am
having to do simply to keep things simple when the NEXT changes happen!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
PHP is all about backwards compatibility.
We only break things that need to be broken. The legacy
str*/str_/string_/array_* functions will still work.
Pierre Joye wrote:
should still work. All the string API methods need to be available on
every pseudo-object regardless of the type. So I don't see any "cleanup"
here either.I do, and again this is purely a theoretical discussion right now.
However I find disturbing the resistance to such a proposal given that
what I hear from our users is a total support to introduce this
concept to PHP, even step by step.So we should better begin to see where are the technical bottlenecks
and figure out a way to solve them instead of arguing about whether we
should do it or not. Because we will have to do it, whether we like it
or not.So a few people want this therefore we all have to have it?
We need to sort out a list of priorities and then perhaps see if there is
a majority demand for each?Since somebody will obviously rewrite key libraries using this 'sexy'
stuff, we are all then forced to have to work with it even if we can ignore
it in our own code. ONE of these days I'd like to get back to putting some
new functions in my own code base. I'm still working on a long list of
'strict' warnings across several projects and libraries :( Work that I
don't make any money from but am having to do simply to keep things simple
when the NEXT changes happen!--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk
Pierre Joye wrote: should still work. All the string API methods need to be available on >every pseudo-object regardless of the type. So I don't see any "cleanup" >here either. I do, and again this is purely a theoretical discussion right now. However I find disturbing the resistance to such a proposal given that what I hear from our users is a total support to introduce this concept to PHP, even step by step. So we should better begin to see where are the technical bottlenecks and figure out a way to solve them instead of arguing about whether we should do it or not. Because we will have to do it, whether we like it or not. So a few people want this therefore we all have to have it? We need to sort out a list of priorities and then perhaps see if there is a majority demand for each? Since somebody will obviously rewrite key libraries using this 'sexy' stuff, we are all then forced to have to work with it even if we can ignore it in our own code. ONE of these days I'd like to get back to putting some new functions in my own code base. I'm still working on a long list of 'strict' warnings across several projects and libraries :( Work that I don't make any money from but am having to do simply to keep things simple when the NEXT changes happen!
Andrew Faulds wrote:> PHP is all about backwards compatibility.
We only break things that need to be broken. The legacy
str*/str_/string_/array_* functions will still work.
You are still missing the point here.
That the old stuff still works most of the time would be nice if one could rely
on old code STILL working several versions later. The problem comes when someone
'updates' a key library to new stuff that does not then play a well with the
legacy stuff. So we have to manage which versions of libraries are compatible,
and as in the case of security problems manage our own backport of fixes to keep
compatible versions save. I'm having to update the 'strict' compliance simply to
keep in line with libraries that have also 'been updated' just to keep standing
still.
In the case of this new style of writing string and array stuff, they have to
play transparently with the legacy variables when a library is used in a legacy
project. So what is the point of yet another method of doing the same thing we
have been doing happily for years? If you must have array and string object,
just add an optional extension and then we can make sure it never gets used for
library projects :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
wat
The pseudo- prefix means something. These scalar and array vars are
unchanged. The methods are implemented via an engine shortcut, not by
making them objects.
Pierre Joye wrote:should still work. All the string API methods need to beavailable on
>every pseudo-object regardless of the type. So I don't see
any
"cleanup"
>here either.I do, and again this is purely a theoretical discussion right now. However I find disturbing the resistance to such a proposal giventhat
what I hear from our users is a total support to introduce this
concept to PHP, even step by step.So we should better begin to see where are the technicalbottlenecks
and figure out a way to solve them instead of arguing about
whether we
should do it or not. Because we will have to do it, whether we
like it
or not.So a few people want this therefore we all have to have it? We need to sort out a list of priorities and then perhaps see ifthere is a
majority demand for each?Since somebody will obviously rewrite key libraries using this 'sexy'stuff,
we are all then forced to have to work with it even if we can ignore
it in
our own code. ONE of these days I'd like to get back to putting some
new
functions in my own code base. I'm still working on a long list of
'strict'
warnings across several projects and libraries :( Work that I don't
make any
money from but am having to do simply to keep things simple when the
NEXT
changes happen!Andrew Faulds wrote:> PHP is all about backwards compatibility.
We only break things that need to be broken. The legacy
str*/str_/string_/array_* functions will still work.You are still missing the point here.
That the old stuff still works most of the time would be nice if one could
rely on old code STILL working several versions later. The problem comes
when someone 'updates' a key library to new stuff that does not then play a
well with the legacy stuff. So we have to manage which versions of
libraries are compatible, and as in the case of security problems manage
our own backport of fixes to keep compatible versions save. I'm having to
update the 'strict' compliance simply to keep in line with libraries that
have also 'been updated' just to keep standing still.In the case of this new style of writing string and array stuff, they have
to play transparently with the legacy variables when a library is used in a
legacy project. So what is the point of yet another method of doing the
same thing we have been doing happily for years? If you must have array and
string object, just add an optional extension and then we can make sure it
never gets used for library projects :)--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk
Hi!
So we should better begin to see where are the technical bottlenecks
and figure out a way to solve them instead of arguing about whether we
should do it or not. Because we will have to do it, whether we like it
or not.
No, that's exactly WRONG way to do things. We should first know if it's
good for PHP and only AFTER we know it's good, we should look for
technical bottlenecks. Doing it the wrong way is exactly what got us in
situation that everybody recognizes is messy. Because stuff that was
technically possible (and some things that only seemed possible if you
don't think too hard about them) was done without thinking how it would
behave in all the situations and how the rest of the language would work
with it.
What I do find a bit disturbing is that you think "I know some people
that want it" is a good argument to implement any language feature
despite quite clear problems that were explained to you - that you think
this argument alone is enough to dismiss all these problems as if they
didn't exist. You just wave it away and then you are surprised - where
this resistance is coming from?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
We can have more consistent naming, at least.
I like this idea even more now, it means we could have a set of universal
operations:
$bool->negate(); // true -> false
$num->negate(); // 7 -> -7
$numericString->negate(); // "123" -> -123
$float->negate(); // 3.141592 -> -3.141592
$customVectorType->negate(); // (1, 0.5, -1) -> (-1, -0.5, 1)
//etc.
negate(); is just an example: that's usually done with an operator, I'm
really thinking more of things like sort() here. But you get the idea.
hi Rasmus,
On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:$a = -5;
$b = "-5";echo $a->abs(); // Outputs 5
echo $b->abs(); // should still output 5What has been cleaned here over:
echo abs($a);
echo abs($b);Heh, here is another example where it makes even less sense:
time();sigh.
More seriously... we are not talking about these APIs and I am sure
you know which one I refer to, like the string API and the like.Ok, so for the string API:
$a = 1;
$a->strstr('1');should still work. All the string API methods need to be available on
every pseudo-object regardless of the type. So I don't see any "cleanup"
here either.-Rasmus
On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds ajfweb@googlemail.comwrote:
I think PHP could benefit from making arrays, strings, integers,
floats, and possibly booleans, into "pseudo-objects". By this I mean
that they are not really objects (they are still primitive types and
keep their passing semantics), but they have methods. For instance,
instead of array_keys($array), one could do $array->keys();
How about just creating (in PEAR or PECL) a Php Type Library which lets you
write all the new code you want which treats all these things in a Javaish
OOP way, but leave PHP's functional roots alone?
$str = new String("Foo");
if (3 == $str->length()) echo $str->toUpper();
I think automagically treating actual non-objects as objects is just asking
for massive amounts of confusion. The technical debt PHP would take on
from doing something like this would be... painful.
If you really feel strongly about it, then I'd suggest you grab
pecl/operator as a starting point and create an extension which hooks the
opcodes involved in method calls to route to scalar handlers instead of
producing the error message which they do now. If you want to get clever,
you might even make the prototype classes for the scalar handlers
extensible to override functionality in userspace, but don't tell anyone I
suggested that. :)
-Sara
I never said treat them as objects. I said give them methods. Not the same
thing.
And what do you mean by "technical debt"?
On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds ajfweb@googlemail.comwrote:
I think PHP could benefit from making arrays, strings, integers,
floats, and possibly booleans, into "pseudo-objects". By this I mean
that they are not really objects (they are still primitive types and
keep their passing semantics), but they have methods. For instance,
instead of array_keys($array), one could do $array->keys();How about just creating (in PEAR or PECL) a Php Type Library which lets
you write all the new code you want which treats all these things in a
Javaish OOP way, but leave PHP's functional roots alone?$str = new String("Foo");
if (3 == $str->length()) echo $str->toUpper();I think automagically treating actual non-objects as objects is just
asking for massive amounts of confusion. The technical debt PHP would take
on from doing something like this would be... painful.If you really feel strongly about it, then I'd suggest you grab
pecl/operator as a starting point and create an extension which hooks the
opcodes involved in method calls to route to scalar handlers instead of
producing the error message which they do now. If you want to get clever,
you might even make the prototype classes for the scalar handlers
extensible to override functionality in userspace, but don't tell anyone I
suggested that. :)-Sara
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds ajfweb@googlemail.comwrote:
I never said treat them as objects. I said give them methods. Not the same
thing.
Fair enough, noone is talking about giving them properties or formal class
definitions.
And what do you mean by "technical debt"?
I mean that we'll never escape the functional side of PHP, nor should we
try to. So we're not talking about replacing a set of APIs, we're talking
about duplicating APIs which already exist. More than that, we're talking
about creating a whole new branch of primitive handling in order to give
them methods without actually giving them class methods. I'm not saying
that any of this is difficult to do, I'm asking if it actually gains us
anything which justifies doubling the number of implementations which deal
with string, array, and scalar operation.
Given that you can accomplish this with a PECL extension, my answer is "No,
it doesn't."
-Sara
I'm curious, how do I make my objects have scalar passing semantics, then?
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds ajfweb@googlemail.comwrote:
I never said treat them as objects. I said give them methods. Not the
same thing.Fair enough, noone is talking about giving them properties or formal class
definitions.And what do you mean by "technical debt"?
I mean that we'll never escape the functional side of PHP, nor should we
try to. So we're not talking about replacing a set of APIs, we're talking
about duplicating APIs which already exist. More than that, we're talking
about creating a whole new branch of primitive handling in order to give
them methods without actually giving them class methods. I'm not saying
that any of this is difficult to do, I'm asking if it actually gains us
anything which justifies doubling the number of implementations which deal
with string, array, and scalar operation.Given that you can accomplish this with a PECL extension, my answer is
"No, it doesn't."-Sara
I'm curious, how do I make my objects have scalar passing semantics, then?
How about this?
class String {
protected $string='';
public function __construct($string){
$this->string = $string;
}
public function toUpper(){
$string = clone $this;
$string->string = strtoupper($this->string);
return $string;
}
public function __toString(){
return $this->string;
}
}
$foo = new String('foo');
$bar = $foo->toUpper();
echo $foo; //foo
echo $bar; //FOO
So far we only have the toString magic method. If we had the others, you
could conceivably do this all in userland (at a fairly high performance
cost I would assume).
Cheers,
David
As you suggested initially. Don't make them objects. You can leave them
scalars and still give them methods all from an extension. Not via typical
APIs, granted, but the engine hooks are all in there.
On Thu, Jul 19, 2012 at 4:38 PM, Andrew Faulds ajfweb@googlemail.comwrote:
I'm curious, how do I make my objects have scalar passing semantics, then?
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds ajfweb@googlemail.comwrote:
I never said treat them as objects. I said give them methods. Not the
same thing.Fair enough, noone is talking about giving them properties or formal
class definitions.And what do you mean by "technical debt"?
I mean that we'll never escape the functional side of PHP, nor should we
try to. So we're not talking about replacing a set of APIs, we're talking
about duplicating APIs which already exist. More than that, we're talking
about creating a whole new branch of primitive handling in order to give
them methods without actually giving them class methods. I'm not saying
that any of this is difficult to do, I'm asking if it actually gains us
anything which justifies doubling the number of implementations which deal
with string, array, and scalar operation.Given that you can accomplish this with a PECL extension, my answer is
"No, it doesn't."-Sara
Sara Golemon wrote:
I'm not saying
that any of this is difficult to do, I'm asking if it actually gains us
anything which justifies doubling the number of implementations which deal
with string, array, and scalar operation.Given that you can accomplish this with a PECL extension, my answer is "No,
it doesn't."
And still seems to be the best way even to 'investigate' this? I still have not
had any explanation of what is wrong with ArrayObject? Certainly any changes
need to be mirrored identically in that anyway?
Also perhaps I am just too set in my ways, but while I understand the
needle/haystack complaint, I don't see a major problem that needs everything
changing. Perhaps add the odd alternative as that would be the only BC fix anyway?
Most of the people who complain about these things are not going to change TO
PHP anyway so why keep messing things up for those of us who's livelihood
depends on productivity in PHP!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
And still seems to be the best way even to 'investigate' this? I still
have not had any explanation of what is wrong with ArrayObject? Certainly
any changes need to be mirrored identically in that anyway?Also perhaps I am just too set in my ways, but while I understand the
needle/haystack complaint, I don't see a major problem that needs
everything changing. Perhaps add the odd alternative as that would be the
only BC fix anyway?Most of the people who complain about these things are not going to change
TO PHP anyway so why keep messing things up for those of us who's
livelihood depends on productivity in PHP!
I don't see this as "solving a major problem", sure most of us relies on
IDE's or shear memory to know where needle/haystack should be. But that
does not invalidate that this "feature" is a nice syntax sugar, just like
short arrays and other things were.
Also this does not have to affect anyone's livelihood or productivity, it
will fuel who wants to use it, and maybe the new generation of PHP devs. I
for sure would change from using most string functions to it, but not 100%
of the time, so
really face this as being syntax sugar, which i love, i'm very much focused
on code readability and this makes a lot of sense from context and ease of
understanding, it does not change everything, but its a nice to have.
Technologies and languages evolve, i think its valid to look a new
resources to give people more choices and it goes a long way into making
learning PHP easier for new devs who don't have to suffer our organic api,
which feels
confortable for us who have been at it for over 10 years, but is enough of
a bother to new people I guess.
Anyway, i would love to see this as a alternative, not a replacement, for
some of the string functions and similar things
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Exactly. Much of my focus is making PHP more consistent and logical, and
hence easier to learn. It would be nice if PHP was as easy as Python,
someday. (for example)
And still seems to be the best way even to 'investigate' this? I still
have not had any explanation of what is wrong with ArrayObject? Certainly
any changes need to be mirrored identically in that anyway?Also perhaps I am just too set in my ways, but while I understand the
needle/haystack complaint, I don't see a major problem that needs
everything changing. Perhaps add the odd alternative as that would be the
only BC fix anyway?Most of the people who complain about these things are not going to
change
TO PHP anyway so why keep messing things up for those of us who's
livelihood depends on productivity in PHP!I don't see this as "solving a major problem", sure most of us relies on
IDE's or shear memory to know where needle/haystack should be. But that
does not invalidate that this "feature" is a nice syntax sugar, just like
short arrays and other things were.Also this does not have to affect anyone's livelihood or productivity, it
will fuel who wants to use it, and maybe the new generation of PHP devs. I
for sure would change from using most string functions to it, but not 100%
of the time, so
really face this as being syntax sugar, which i love, i'm very much focused
on code readability and this makes a lot of sense from context and ease of
understanding, it does not change everything, but its a nice to have.Technologies and languages evolve, i think its valid to look a new
resources to give people more choices and it goes a long way into making
learning PHP easier for new devs who don't have to suffer our organic api,
which feels
confortable for us who have been at it for over 10 years, but is enough of
a bother to new people I guess.Anyway, i would love to see this as a alternative, not a replacement, for
some of the string functions and similar things--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Andrew Faulds wrote:
Exactly. Much of my focus is making PHP more consistent and logical, and hence
easier to learn. It would be nice if PHP was as easy as Python, someday. (for
example)
Python easy? I'm HAVING to fix python code as well these days, if it was any
good I might be tempted to move everything to it, but I certainly don't feel the
change would have any point. Eclipse IDE provides easy highlighting and allows
working with the same tools for every language, but that still does not convince
me. Ruby is the same, but I've managed to avoid having to deal with that.
I don't remember PHP ever being 'difficult' ... I started straight in on PHP5
and had live sites just as it dropped off release candidates. I had to watch
PHP4 compatibility for third party projects that still ran on 4 but on the whole
my C/C++/Pascal experience just translated without any problem. I simply can't
see what is 'complicated' but then I did do a masters degree in Digital Systems
back in 1982 when computers came in rooms rather than pockets :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk