Nikita Popov wrote:
I would like to propose making the use of arithmetic/bitwise operators
on arrays, resources and (non-overloaded) objects a TypeError
exception:
https://wiki.php.net/rfc/arithmetic_operator_type_checks
This is inspired by some of the recent discussions, in particular the
ope
Larry Garfield wrote:
On Sun, Mar 29, 2020, at 4:04 PM, Ilija Tovilo wrote:
What you're proposing is a language construct for an *expression*,
which evaluates depending on internal logic to a different value.
Those are sufficiently distinct that I agree they should have distinct
keywords. Plu
Stanislav wrote:
I think "as long as it is not overused" are the key words there. We
have a very limited number of internal classes with operator
overloading
I think the whole point of leaving it to extensions was ensuring it's
not overused. And now I see people arguing "well, if it's availabl
Hi Nikita.
Thanks for your response and the links. I found the search engine you linked
to working well.
The reason I came to think of this issue was not as much to be able to do
function overloading in general, but more from the fact that the discussion
on operator overloading seemed to inv
Hi.
Please excuse me if this has been discussed to death earlier. I've tried
to search for it, but I've come up empty:
https://www.php.net/results.php?
q=function+overloading&l=en&p=all
The recent discussion on operator overloading has highlighted the
relationship between function overloading
Hi guys.
I've searched the archive, but I haven't found anything about this issue.
I notice there exists an RFC for autoloading of functions, or more to the
point, a unified autoloading system for classes, functions, constants and
streams:
https://wiki.php.net/rfc/function_autoloading
Our s
Tyson Andre wrote:
Hi internals,
In PHP, variables are currently scoped to the function scope, and
can't be scoped to a block scope. This makes it difficult to reason
about how a variable will actually be used at a glance, especially in
long functions, or top-level statement lists of a file.
(
Hi Rowan.
I agree that this makes sense. However, as someone else pointed out, one
problem with interfaces is that they constrain the types that may be used.
We have our own Money, Percentage, PricePerMm, etc. types that we'd like
to define operators for, how can you define an interface in PH
On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote:
How many of you would prefer a interface solution for operator
overloading?
I wonder if the RFC voting should include the option to choose between
either the magic method approach (with the syntax proposed in the
current
RFC version) or using inter
Mike Schinkel wrote:
On Feb 21, 2020, at 6:17 PM, Larry Garfield
wrote:
Separate visibility for internal and external access is a separate
matter. (Also potentially useful, but not part of the write-once
proposal at the moment.)
This just hit me, so I think I will mention it.
The culture
jan.h.boeh...@gmx.de wrote:
based on the discussions here (https://externals.io/message/108300)
and here (https://github.com/php/php-src/pull/5156), I have created a
proper RFC for userspace operator overloading:
https://wiki.php.net/rfc/userspace_operator_overloading
The main differences to my
t a bug...
Regards,
Terje
>From: "Christian Schneider" <[EMAIL PROTECTED]>
>To: "Terje Slettebø" <[EMAIL PROTECTED]>
>Sent: Friday, September 15, 2006 11:38 AM
>Subject: Re: [PHP-DEV] Re: Why isn't base class constructors or
destructorsrequired t
lieve me!
Why would you not call the base class constructor/destructor? Could you give
an example?
Regards,
Terje
2006/9/15, Terje Slettebø <[EMAIL PROTECTED]>:
>
> >From: "Marcus Boerger" <[EMAIL PROTECTED]>
>
> > PHP is not C++ and speaking of constructors
>From: "Marcus Boerger" <[EMAIL PROTECTED]>
> PHP is not C++ and speaking of constructors and destrcutors PHP goes
morethe
> Delphi way.
I'd also like to know _why_ constructors/destructors are less fit for PHP,
than these other languages? How can you be sure that objects of a class are
properly
> >> When would the constructor be called automatically? I've used Delphi
> >> and you use the inherit verb (or inherited - long time ago - can't
> >> remember exactly). In PHP parent::__construct (though I think
> >> parent::__METHOD__ would be cleaner as this removes ambiguity on the
> >> actual
base classes and member variables (unless these are explicitly constructed
in these lists), it may not be much point in trying to do it that way in
PHP.
Regards,
Terje
> On 14/09/06, Terje Slettebø <[EMAIL PROTECTED]> wrote:
> > > Terje Slettebø wrote:
> > > > The a
P.S. This also just covers _half_ of the equation; destructors are not
covered.
- Original Message -
From: "Terje Slettebø" <[EMAIL PROTECTED]>
To: "Johannes Schlueter" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, September 14, 2006 9:17 PM
Subject: Re
" is given. Only the
conclusions:
"Conclusions:
- We add a flag to the class structure to record this
- We do not add new syntax for this to userland"
Reading this again, I'm wondering if I interpret it right in that there will
be no way to enforce this in PHP code? If so, why not
Hi all.
Another issue. :) As usual, I searched the archive first, but found only a
few postings from 2004 on the subject, without much clarification, so I'd
like to pose the question again. If this has been discussed, I'd welcome
hearing what was the outcome of it.
In PHP, unlike other languages
> Terje Slettebø wrote:
> > The above was a contrived example, meant to illustrate the point. What's
so
> > bad about it? That it doesn't check the return value?
>
> I am not worried about the return value of the method. I am concerned
> that $this->something
>From: "Brian Moon" <[EMAIL PROTECTED]>
> > --- Start ---
> >
> > class Something
> > {
> > public function __construct()
> > {
> > // Oops, forgot to initialise $this->something...
> > }
> >
> > public function f()
> > {
> > return $this->something;
> > }
> >
> > private $so
I am sure that the speed up due to JIT loading would balance the
autoloading overhead.
Please tell me what you think about it.
Regards
François
Terje Slettebø wrote:
> > > In either of the above cases, you specify where a function belongs,
both
> > > where it's defined
> > In C++, it's possible to declare member functions "const" meaning they
don't
> > change the object they operate on. This can help reason about programs,
> > because if you have something like (PHP syntax):
>
> It would be pretty hard to enforce in PHP - how do you know the object
> is not chang
> Terje Slettebø wrote:
> > I'd say that's debatable. :) Yes, it can make it more convenient to
handle
> > data coming from outside the script (such as forms), but it can also
hide
> > bugs. While it can be argued that conversions between, say, arithmetic
types
>
>From: "Richard Quadling" <[EMAIL PROTECTED]>
> On 13/09/06, Terje Slettebø <[EMAIL PROTECTED]> wrote:
> > >From: "Richard Quadling" <[EMAIL PROTECTED]>
> >
> > > On 12/09/06, Terje Slettebø <[EMAIL PROTECTED]&
Hi Marcus.
> long ago we decided against supporting it in the array functions.
Ok, thanks. Could I ask what the reasons were (Alternatively get a pointer
to the discussion)?
Regards,
Terje
> best regards
> marcus
>
> Wednesday, September 13, 2006, 8:39:57 AM, you wrote:
>
> > Hi all.
>
> > (
>From: "Richard Quadling" <[EMAIL PROTECTED]>
> On 12/09/06, Terje Slettebø <[EMAIL PROTECTED]> wrote:
> > function f(Something $value) /** @return SomethingElse */
> > {
> > // ...
> > }
>
> One of the good things about PHP is the loos
(This may be considered too radical for some, but I ask, anyway... Also, if
there's a more appropropriate place to ask such questions, let me know, but
as this is the developer's list, it seemed like the right place)
In C++, it's possible to declare member functions "const" meaning they don't
chan
Hi all.
(Again, I've searched the archives, but haven't found anything on this one)
The ArrayAccess interface allows one to essentially overload the index
operator "[]" [1], which is nice, as it makes it possible to implement
things like type-checked associative arrays, variants, tuples, etc. Howe
ith other things. :)
- Original Message -
From: "Marcus Boerger" <[EMAIL PROTECTED]>
To: "Terje Slettebø" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, September 12, 2006 11:00 PM
Subject: Re: [PHP-DEV] Return type hints
> Hello Terje,
>
> at some poin
Hi again.
To something different: I've read [1] that return type hints for functions
have been considered for PHP 6, possibly even planned. In [1], it says: "We
will add support for type-hinted return values."
I've searched the archives, but haven't found much on this since about a
year ago. Does
> > In either of the above cases, you specify where a function belongs, both
> > where it's defined, and where it's used (either through full
qualification,
> > or a shorter one, using "import"). I'm not arguing for a function to
> > "magically" become a part of a class/module/whatever, if you thou
>On 9/11/06, Terje Slettebø <[EMAIL PROTECTED]> wrote:
>> Please, people: The availability of free (non-member) functions in PHP
(as
>> in C/C++) is one advantage it has over Java, where everything _has_ to be
a
>> class. So in Java, instead of being able to write &qu
> > Or "namespaces"... Or just plain "modules". Classes is not the only way
to
> > group things, and may not be the best (namespaces can typically be
> >
> Oh, of course it's not the only way. It's the only way native to PHP
though.
Yes.
> > re-opened, so functions and classes belonging to a name
> >> Maybe a dump question, but wouldn't it get considered only, AFTER PHP
has
> >> found that the function does not exist?
>
> Technically, this can be done - i.e. engine can be patched so that
> instead of throwing an error or refusing the call it would call
> appropriate function which would all
Hi Pierre.
> > P.S: As an aside: Why is everybody (?) replying to both the list _and_
the
> > poster? If you post, isn't it safe to assume you're actually on the
list, or
> > am I missing something?
>
> It is a common usage here. Some uses nntp, other mails (and filters,
etc..).
Ok. It's just th
e list, or
am I missing something?
- Original Message -
From: "Marcus Boerger" <[EMAIL PROTECTED]>
To: "Terje Slettebø" <[EMAIL PROTECTED]>
Cc: "Hannes Magnusson" <[EMAIL PROTECTED]>;
Sent: Sunday, September 10, 2006 5:35 PM
Subject: Re: [PHP-DEV] R
y), but in the first call to that function, you typically haven't
instantiated the class, before...
Regards,
Terje
- Original Message -
From: "Hannes Magnusson" <[EMAIL PROTECTED]>
To: "Terje Slettebø" <[EMAIL PROTECTED]>
Cc:
Sent: Sunday, Septemb
Hi all.
I don't know if this has been discussed before (I've not found it from doing
a search), but if it has, please provide me with a link to the discussion.
__autoload() is very convenient, but it has one problem: While classes
defined in the __autoload() function (via an include) are accessib
> >> From: "Andrei Zmievski" <[EMAIL PROTECTED]>
> >
> >> Attention: you have posted C++ template code on PHP mailing list.
> >> Please
> >> pay a $100 fine immediately and carefully proceed to the exit.
> >
> > Hehe... I do hope this is a joke (it would seem rather closed-minded,
> > otherwise). I
> Andrei Zmievski wrote:
> > Attention: you have posted C++ template code on PHP mailing list. Please
> > pay a $100 fine immediately and carefully proceed to the exit.
>
> Luckily my peril sensitive sunglasses turned black at the first line
> before I even managed to read the template part of the
>From: "Andrei Zmievski" <[EMAIL PROTECTED]>
> Attention: you have posted C++ template code on PHP mailing list. Please
> pay a $100 fine immediately and carefully proceed to the exit.
Hehe... I do hope this is a joke (it would seem rather closed-minded,
otherwise). I don't think anybody would ha
(Ditto remark here as the posting I just sent: Please direct any followup
privately)
>From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>An advantage of function objects in C++ is that they can be used where
> TS>>functions are expected. Nevertheless, there are some features that can
be
>
> Dep
>From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>No, you don't have to go that far. For starters, one could allow
function
> TS>>(and possibly operator) overloading, based on type hints. The
following is
> TS>>legal PHP5:
>
> That will already open the can of worms. And make each function cal
>From: "Darrell Brogdon" <[EMAIL PROTECTED]>
>I don't think its really a resentment (for the most part) against OO in
>PHP even if it seems that way. One of the stated goals of PHP is to
>have a low learning curve and this is something it does very well. I'm
>sure you can agree that OO concepts
>From: "George Schlossnagle" <[EMAIL PROTECTED]>
>> Yes, I know that operator overloading, as well as statically
>> typed/dynamically typed, type checking, etc. are hotly debated topics,
>> and
>> that can be healthy, at least as long as there are reasonable
>> arguments for
>> either side. What I
>From: "David Zülke" <[EMAIL PROTECTED]>
>No offense, but before even thinking about operator overloading support,
>really useful and crucial stuff like namespaces or Unicode support should
be
>tackled first.
None taken. :) Part of the reason for posting was to find out what people
would like to
>From: "Derick Rethans" <[EMAIL PROTECTED]>
>> > TS>>As someone said, "Syntactic sugar matters, or we'd all be
>> > TS>>writing assembly code." :)
>> >
>> > Someone was wrong. There are syntax constructs that allow to reduce
>> > complexity of the code, and there are constructs that make the code
>From: "Derick Rethans" <[EMAIL PROTECTED]>
Oh, hello. I recognise your name as one of the other authors of the book
"PHP 5 Power Programming", which I've recently got, and which looks very
good. It seems like all the "big guns" are on this list. :) (similar to
comp.lang.c++.moderated and comp.std
> From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>across, given what what operator overloading is about). As I've
pointed out
> TS>>in other postings in this thread, operator overloading is about much
more
> TS>>than "just" "syntactic sugar". In C++, for example, it enables
important
>
> I th
> From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>When you say "typeless", i think you mean "not statically typed".
>
> Not only, but in this case it is the main trait I meant.
...Because PHP has types, so I felt it was a misnomer to call it "typeless".
> TS>>through this discussion elsewhe
> From: "Jani Taskinen" <[EMAIL PROTECTED]>
>
> C++ is not PHP and the sooner you realize this the better it will be.
I do realise it. However, I don't accept that as an argument against things
like operator overloading, which is found in scripting languages comparable
to PHP.
> Adding operator o
> TS>>As someone said, "Syntactic sugar matters, or we'd all be writing
assembly
> TS>>code." :)
>
> Someone was wrong. There are syntax constructs that allow to reduce
> complexity of the code, and there are constructs that make the code have
> the same complexity but look prettier to the eyes of
>From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>(***) This is how it's done in C++ (actually, a dummy int parameter),
which
> TS>>is a bit of a hack, to be able to specify both the pre- and
>
> In C++, functions differ by argument. In PHP, they don't.
Yes, but a different way might be used
> TS>>If $a is an object of a class, then they would both be in the class
> TS>>definition. One is called "add", and the other is called "operator+".
What's
> TS>>the problem with that?
>
> The problem is that you can't really know what $a is - PHP is typeless.
When you say "typeless", i think you
> SB>> patch [1] by Johannes Schl?ter that has been floating around for a
> SB>> while?
>
> 1. I personally don't think operator overloading is a good idea. It
> doesn't add you anything you couldn't do without it the same way - it's
> pure syntax sugar.
As someone said, "Syntactic sugar matters,
> On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
> [EMAIL PROTECTED] (Derick Rethans) wrote:
>
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> > > Derick Rethans wrote:
> > > > Use C++/Java if you want this.
> > >
> > > Java does not support operator overloading.
> >
> > So, that means PHP should
> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > This adds operator overloading to user classes?
> >
> > Yes, have a look at Johannes' Complex example [1].
>
> Okay, mega Yuck then. Although it looks cool, I consider it as a bad
> practise. It confuses the hell out
> Derick Rethans wrote:
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> >>Derick Rethans wrote:
> >>>This adds operator overloading to user classes?
> >> Yes, have a look at Johannes' Complex example [1].
> >
> > Okay, mega Yuck then. Although it looks cool, I consider it as a bad
> > pract
59 matches
Mail list logo
