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 mov
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" wrote:
> On Fri, Jul 20, 2012 at 10:33 AM, Lester Caine wrote:
>
> >
> > And still seems
On Fri, Jul 20, 2012 at 10:33 AM, Lester Caine 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 I am just too
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 "
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 wrote:
> I'm curious, how do I make my objects
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" wrote:
>
How about this?
class String {
protected $string='';
public function __construct($string){
$this->string =
I'm curious, how do I make my objects have scalar passing semantics, then?
On Jul 20, 2012 12:35 AM, "Sara Golemon" wrote:
>
>
> On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds wrote:
>
>> I never said treat them as objects. I said give them methods. Not the
>> same thing.
>>
> Fair enough, noone
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds wrote:
> 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 nev
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" wrote:
>
>
> On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds wrote:
>
>> I think PHP could benefit from making arrays, strings, integ
On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds wrote:
> 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), bu
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
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" wrote:
> Pierre Joye wrote:
>>
>> should still work. All the string API metho
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
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" wrote:
> Pierre Joye wrote:
>
>> should still work. All the string API methods need to be available on
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 p
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-
On Thu, Jul 19, 2012 at 5:49 PM, Rasmus Lerdorf 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 fi
On 07/19/2012 12:25 AM, Pierre Joye wrote:
> hi Rasmus,
>
> On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf 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
>>
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" 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 J
hi Rasmus,
On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf 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 has bee
On Wed, Jul 18, 2012 at 6:16 PM, Rasmus Lerdorf 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
> >>> wrote:
> Hi!
>
> >>
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
>>> wrote:
Hi!
> See the other answers, clear APIs, no more argument mess, cleanness.
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 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
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 pr
> 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
On 07/18/2012 01:02 AM, Pierre Joye wrote:
> hi,
>
> On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev 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 u
hi,
On Wed, Jul 18, 2012 at 7:50 PM, Ferenc Kovacs 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
> variable typ
2012.07.18. 18:55, "Stas Malyshev" 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 "thi
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" wrote:
> Hi!
>
> > Er, sorry, accidental capslock. This IS a new API. That was an example.
> > I'm not saying j
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 anythi
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" wrote:
> Hi!
>
> > enough but I
hi Stas,
On Wed, Jul 18, 2012 at 6:35 PM, Stas Malyshev 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 cleanup more
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() i
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" wrote:
> 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
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 a
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 "
hi,
On Wed, Jul 18, 2012 at 11:24 AM, Lester Caine 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 existing functions o
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-o
hi,
On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev 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 us
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 lo
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev 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.
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,
hi!
On Tue, Jul 17, 2012 at 10:30 PM, Stas Malyshev 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 types. Just a
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
hi,
On Tue, Jul 17, 2012 at 7:03 PM, Stas Malyshev 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
> what -> means an
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 = getSec
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: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
so
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
> whi
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
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
complet
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(
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 ne
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, "Rasm
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" wrote:
> On 07/17/2012 03:07 AM, Pierre Joye wrote:
> > hi,
> >
> > On Tue, Jul 17, 20
On 07/17/2012 03:07 AM, Pierre Joye wrote:
> hi,
>
> On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes 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 th
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 somethin
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" wrote:
> On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye wrote:
>
> On Tue, J
hi Gustavo,
On Tue, Jul 17, 2012 at 12:21 PM, Gustavo Lopes 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 OP), but for that
> the
On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye wrote:
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes
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(...
I think strings are even more important, they have an even messier API than
arrays.
On Jul 17, 2012 11:07 AM, "Pierre Joye" wrote:
> hi,
>
> On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes
> wrote:
>
> > Let's ignore empty arguments like "make[s] PHP feel modern". That aside,
> the
> > main argum
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes 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
Em Tue, 17 Jul 2012 01:27:10 +0200, Andrew Faulds
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
On Mon, Jul 16, 2012 at 7:27 PM, Andrew Faulds 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 think PHP could benef
On Tue, Jul 17, 2012 at 1:27 AM, Andrew Faulds wrote:
> 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 fun
65 matches
Mail list logo
