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 ajf...@googlemail.comwrote:
I'm curious, how
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
On Fri, Jul 20, 2012 at 10:33 AM, Lester Caine les...@lsces.co.uk wrote:
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
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)
On Jul 20, 2012 10:57 AM, Rafael Dohms lis...@rafaeldohms.com.br wrote:
On Fri, Jul 20, 2012 at 10:33 AM, Lester Caine
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
hi Rasmus,
On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf ras...@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 5
What
Right, because I've never got them the wrong way round, that is completely
logical, and this syntax makes it much harder.
On Jul 19, 2012 1:17 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/18/2012 05:10 PM, David Muir wrote:
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02
On 07/19/2012 12:25 AM, Pierre Joye wrote:
hi Rasmus,
On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf ras...@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
On Thu, Jul 19, 2012 at 5:49 PM, Rasmus Lerdorf ras...@lerdorf.com 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
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();
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
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.
On Jul 19, 2012 5:36 PM, Lester Caine les...@lsces.co.uk wrote:
Pierre Joye wrote:
should still work. All the string API methods need to be
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
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.
On Jul 19, 2012 6:24 PM, Lester Caine les...@lsces.co.uk wrote:
Pierre Joye wrote:
should still work. All the
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
On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds ajf...@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
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 Jul 19, 2012 9:52 PM, Sara Golemon poll...@php.net wrote:
On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds ajf...@googlemail.comwrote:
I think PHP could benefit from
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds ajf...@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
I'm curious, how do I make my objects have scalar passing semantics, then?
On Jul 20, 2012 12:35 AM, Sara Golemon poll...@php.net wrote:
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds ajf...@googlemail.comwrote:
I never said treat them as objects. I said give them methods. Not the
same
On 20/07/12 09:38, Andrew Faulds wrote:
I'm curious, how do I make my objects have scalar passing semantics, then?
On Jul 20, 2012 12:35 AM, Sara Golemon poll...@php.net wrote:
How about this?
class String {
protected $string='';
public function __construct($string){
hi!
On Tue, Jul 17, 2012 at 10:30 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
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
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
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev smalys...@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
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
hi,
On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalys...@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
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
hi,
On Wed, Jul 18, 2012 at 11:24 AM, Lester Caine les...@lsces.co.uk wrote:
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
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
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
It would probably be passed as first param to functions, or passed as
$this, like other methods.
On Jul 18, 2012 4:27 PM, Amaury Bouchard ama...@amaury.net wrote:
Seems a lot like another syntactic sugar.
Like in Lua, where you can write
obj:method(12)
instead of
obj.method(obj, 12)
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()
hi Stas,
On Wed, Jul 18, 2012 at 6:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
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
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.
On Jul 18, 2012 5:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
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
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.
On Jul 18, 2012 5:54 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Er, sorry, accidental capslock. This IS a new API. That was an example.
2012.07.18. 18:55, Stas Malyshev smalys...@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.
hi,
On Wed, Jul 18, 2012 at 7:50 PM, Ferenc Kovacs tyr...@gmail.com wrote:
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
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev smalys...@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,
I think there is something we can do around this...
Reviewing the php array functions it seems to me that a new API would benefit
from some sort of more intuitive organization, possibly around meta concepts
specific to use.
For example, I want to re-order an array (order is a meta-concept in
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
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You
On 07/18/2012 05:10 PM, David Muir wrote:
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalys...@sugarcrm.com wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
On Wed, Jul 18, 2012 at 6:16 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/18/2012 05:10 PM, David Muir wrote:
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalys...@sugarcrm.com wrote:
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@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
I think strings are even more important, they have an even messier API than
arrays.
On Jul 17, 2012 11:07 AM, Pierre Joye pierre@gmail.com wrote:
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
Let's ignore empty arguments like make[s] PHP feel modern.
On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye wrote:
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes
glo...@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,
hi Gustavo,
On Tue, Jul 17, 2012 at 12:21 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
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
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 Jul 17, 2012 11:21 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye
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
On 07/17/2012 03:07 AM, Pierre Joye wrote:
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@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
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.
On Jul 17, 2012 3:04 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/17/2012 03:07 AM, Pierre Joye wrote:
hi,
On Tue, Jul
On 07/17/2012 08:06 AM, Andrew Faulds wrote:
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
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
On 17.07.2012, at 21:03, Stas Malyshev wrote:
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.
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
On 17.07.2012, at 21:50, Stas Malyshev wrote:
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
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
On 17.07.2012, at 23:01, Stas Malyshev wrote:
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
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';
On 17.07.2012, at 23:20, Stas Malyshev wrote:
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 =
hi,
On Tue, Jul 17, 2012 at 7:03 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
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
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
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
On Tue, Jul 17, 2012 at 1:27 AM, Andrew Faulds ajf...@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,
On Mon, Jul 16, 2012 at 7:27 PM, Andrew Faulds ajf...@googlemail.com wrote:
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
Em Tue, 17 Jul 2012 01:27:10 +0200, Andrew Faulds ajf...@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,
66 matches
Mail list logo
