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
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.
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
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
Hi.
Please excuse me if this has been discussed to death earlier. I've tried
to search for it, but I've come up empty:
https://www.php.net/results.php?
q=function+overloading=en=all
The recent discussion on operator overloading has highlighted the
relationship between function overloading and
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
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
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
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
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
When would the constructor be called automatically? I've used Delphi
and you use the inherit verb (or inherited - long time ago - can't
remember exactly). In PHP parent::__construct (though I think
parent::__METHOD__ would be cleaner as this removes ambiguity on the
actual name for all
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
the base class constructor/destructor? Could you give
an example?
Regards,
Terje
2006/9/15, Terje Slettebø [EMAIL PROTECTED]:
From: Marcus Boerger [EMAIL PROTECTED]
PHP is not C++ and speaking of constructors and destrcutors PHP goes
morethe
Delphi way.
I'd also like to know _why_
]
To: Terje Slettebø [EMAIL PROTECTED]
Sent: Friday, September 15, 2006 11:38 AM
Subject: Re: [PHP-DEV] Re: Why isn't base class constructors or
destructorsrequired to be called?
Terje Slettebø wrote:
Naturally, but is it unreasonable to think that there's a reason for the
way
things work in PHP
Terje Slettebø wrote:
The above was a contrived example, meant to illustrate the point. What's
so
bad about it? That it doesn't check the return value?
I am not worried about the return value of the method. I am concerned
that $this-something is unset yet does not throw a notice
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
the
conclusions:
Conclusions:
- We add a flag to the class structure to record this
- We do not add new syntax for this to userland
Reading this again, I'm wondering if I interpret it right in that there will
be no way to enforce this in PHP code? If so, why not?
Regards,
Terje
Terje Slettebø wrote
in trying to do it that way in
PHP.
Regards,
Terje
On 14/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
Terje Slettebø wrote:
The above was a contrived example, meant to illustrate the point.
What's
so
bad about it? That it doesn't check the return value?
I am not worried about
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.
(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
From: Richard Quadling [EMAIL PROTECTED]
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
One of the good things about PHP is the loose typing (1.00 == 1 == 1
sort of thing as I understand it). This has been
Hi Marcus.
long ago we decided against supporting it in the array functions.
Ok, thanks. Could I ask what the reasons were (Alternatively get a pointer
to the discussion)?
Regards,
Terje
best regards
marcus
Wednesday, September 13, 2006, 8:39:57 AM, you wrote:
Hi all.
(Again,
Terje Slettebø wrote:
I'd say that's debatable. :) Yes, it can make it more convenient to
handle
data coming from outside the script (such as forms), but it can also
hide
bugs. While it can be argued that conversions between, say, arithmetic
types
(int and floats) may be useful, allowing
In C++, it's possible to declare member functions const meaning they
don't
change the object they operate on. This can help reason about programs,
because if you have something like (PHP syntax):
It would be pretty hard to enforce in PHP - how do you know the object
is not changed,
to JIT loading would balance the
autoloading overhead.
Please tell me what you think about it.
Regards
François
Terje Slettebø wrote:
In either of the above cases, you specify where a function belongs,
both
where it's defined, and where it's used (either through full
qualification
From: Brian Moon [EMAIL PROTECTED]
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
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
PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Tuesday, September 12, 2006 11:00 PM
Subject: Re: [PHP-DEV] Return type hints
Hello Terje,
at some point i might find time to do something. I guess all others who
could do something in that area are occupied
Maybe a dump question, but wouldn't it get considered only, AFTER PHP
has
found that the function does not exist?
Technically, this can be done - i.e. engine can be patched so that
instead of throwing an error or refusing the call it would call
appropriate function which would allow for
Or namespaces... Or just plain modules. Classes is not the only way
to
group things, and may not be the best (namespaces can typically be
Oh, of course it's not the only way. It's the only way native to PHP
though.
Yes.
re-opened, so functions and classes belonging to a namespace can
On 9/11/06, Terje Slettebø [EMAIL PROTECTED] wrote:
Please, people: The availability of free (non-member) functions in PHP
(as
in C/C++) is one advantage it has over Java, where everything _has_ to be
a
class. So in Java, instead of being able to write sqrt(number), you
have
to write Math
In either of the above cases, you specify where a function belongs, both
where it's defined, and where it's used (either through full
qualification,
or a shorter one, using import). I'm not arguing for a function to
magically become a part of a class/module/whatever, if you thought so
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
instantiated the class, before...
Regards,
Terje
- Original Message -
From: Hannes Magnusson [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Sunday, September 10, 2006 4:44 PM
Subject: Re: __autoloading and functions
Hello Terje
What are you talking
: Marcus Boerger [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: Hannes Magnusson [EMAIL PROTECTED];
internals@lists.php.net
Sent: Sunday, September 10, 2006 5:35 PM
Subject: Re: [PHP-DEV] Re: __autoloading and functions
Hello Terje,
it hasbeendiscussed and the conclusion
Hi Pierre.
P.S: As an aside: Why is everybody (?) replying to both the list _and_
the
poster? If you post, isn't it safe to assume you're actually on the
list, or
am I missing something?
It is a common usage here. Some uses nntp, other mails (and filters,
etc..).
Ok. It's just that it's
Andrei Zmievski wrote:
Attention: you have posted C++ template code on PHP mailing list. Please
pay a $100 fine immediately and carefully proceed to the exit.
Luckily my peril sensitive sunglasses turned black at the first line
before I even managed to read the template part of the code
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
From: Stanislav Malyshev [EMAIL PROTECTED]
TSNo, you don't have to go that far. For starters, one could allow
function
TS(and possibly operator) overloading, based on type hints. The
following is
TSlegal PHP5:
That will already open the can of worms. And make each function call to go
(I don't mind this discussion, but as several have asked for this subthread
on overloading be ended, it may be best to do so)
On Thu, 2005-02-03 at 19:58, Terje Slettebø wrote:
From: Stig S. Bakken [EMAIL PROTECTED]
Oh, and the comment about Code should be readable, not cuddly-cute
Derick Rethans wrote:
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Derick Rethans wrote:
This adds operator overloading to user classes?
Yes, have a look at Johannes' Complex example [1].
Okay, mega Yuck then. Although it looks cool, I consider it as a bad
practise. It confuses the
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Derick Rethans wrote:
This adds operator overloading to user classes?
Yes, have a look at Johannes' Complex example [1].
Okay, mega Yuck then. Although it looks cool, I consider it as a bad
practise. It confuses the hell out of people
On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Derick Rethans wrote:
Use C++/Java if you want this.
Java does not support operator overloading.
So, that means PHP shouldn't get it either,
SB patch [1] by Johannes Schl?ter that has been floating around for a
SB while?
1. I personally don't think operator overloading is a good idea. It
doesn't add you anything you couldn't do without it the same way - it's
pure syntax sugar.
As someone said, Syntactic sugar matters, or we'd
TSIf $a is an object of a class, then they would both be in the class
TSdefinition. One is called add, and the other is called operator+.
What's
TSthe problem with that?
The problem is that you can't really know what $a is - PHP is typeless.
When you say typeless, i think you mean not
From: Stig S. Bakken [EMAIL PROTECTED]
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Andi Gutmans wrote:
Comments/Flames/Praises to this list :)
Just curious: Have you considered adding the operator overloading
patch [1] by Johannes Schlüter that has been floating around for a
From: Stanislav Malyshev [EMAIL PROTECTED]
TS(***) This is how it's done in C++ (actually, a dummy int parameter),
which
TSis a bit of a hack, to be able to specify both the pre- and
In C++, functions differ by argument. In PHP, they don't.
Yes, but a different way might be used for PHP.
TSAs someone said, Syntactic sugar matters, or we'd all be writing
assembly
TScode. :)
Someone was wrong. There are syntax constructs that allow to reduce
complexity of the code, and there are constructs that make the code have
the same complexity but look prettier to the eyes of the writer.
From: Jani Taskinen [EMAIL PROTECTED]
On Thu, 3 Feb 2005, Terje Slettebø wrote:
Why would it be ok there, but not in PHP? It also exists in other
scripting
languages, such as Python and Perl.
PHP is not Perl or Python or add-your-favorite-language-here.
That's not an argument
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
looking forward to reading it.
On Feb 3, 2005, at 1:58 PM, Terje Slettebø wrote:
Hm, I'm surprised by this response from someone who's name I recognise
as an
active PHP contributor. The answer strikes me as either arrogant and/or
ignorant (note: I'm not saying you are that, but that's how
From: Stanislav Malyshev [EMAIL PROTECTED]
TSWhen you say typeless, i think you mean not statically typed.
Not only, but in this case it is the main trait I meant.
...Because PHP has types, so I felt it was a misnomer to call it typeless.
TSthrough this discussion elsewhere - a variable
From: Stanislav Malyshev [EMAIL PROTECTED]
TSacross, given what what operator overloading is about). As I've
pointed out
TSin other postings in this thread, operator overloading is about much
more
TSthan just syntactic sugar. In C++, for example, it enables
important
I think you did not
From: Derick Rethans [EMAIL PROTECTED]
Oh, hello. I recognise your name as one of the other authors of the book
PHP 5 Power Programming, which I've recently got, and which looks very
good. It seems like all the big guns are on this list. :) (similar to
comp.lang.c++.moderated and comp.std.c++ for
From: Derick Rethans [EMAIL PROTECTED]
TSAs someone said, Syntactic sugar matters, or we'd all be
TSwriting assembly code. :)
Someone was wrong. There are syntax constructs that allow to reduce
complexity of the code, and there are constructs that make the code
have
the same
From: David Zülke [EMAIL PROTECTED]
No offense, but before even thinking about operator overloading support,
really useful and crucial stuff like namespaces or Unicode support should
be
tackled first.
None taken. :) Part of the reason for posting was to find out what people
would like to have in
From: Greg Beaver [EMAIL PROTECTED]
Terje Slettebø wrote:
1) $result=$c1.multiply($c2).divide($c1.add($c2));
2) $result=($c1 * $c2) / ($c1 + $c2);
They sure aren't to me. Moreover, they are not the same: operator
overloading enable you to use infix notation, whereas functions use
From: Christian Schneider [EMAIL PROTECTED]
Terje Slettebø wrote:
Those who are experienced enough to shoot themselves in the foot, but
not
experienced enough to aim properly, :) might, however, obfuscate code
with
misuse of more advanced language constructs (variable variables
From: Jani Taskinen [EMAIL PROTECTED]
On Thu, 3 Feb 2005, Terje Slettebø wrote:
From: Jani Taskinen [EMAIL PROTECTED]
On Thu, 3 Feb 2005, Terje Slettebø wrote:
Why would it be ok there, but not in PHP? It also exists in other
scripting
languages, such as Python and Perl
From: George Schlossnagle [EMAIL PROTECTED]
Yes, I know that operator overloading, as well as statically
typed/dynamically typed, type checking, etc. are hotly debated topics,
and
that can be healthy, at least as long as there are reasonable
arguments for
either side. What I decried wasn't
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
62 matches
Mail list logo
