Hello Umberto,
Monday, October 15, 2007, 3:36:22 PM, you wrote:
> Posting to newsgroup php.internals, Stanislav Malyshev wrote:
>> > only reason to use type hints - to ensure the method is used
>> > correctly and build more robust applications), it is better to tell
>>
>> BTW, I'm not sure how
On 17/10/2007, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > suit fully fitted) "catch-up". (Hey when has documentation EVER been
> > ahead of the game!?!).
>
> Always? Otherwise there would be no need for documentation, if
> everything was in the code. Some people even start with writing docs
suit fully fitted) "catch-up". (Hey when has documentation EVER been
ahead of the game!?!).
Always? Otherwise there would be no need for documentation, if
everything was in the code. Some people even start with writing docs and
only then implement the actual code. Of course, it is not always t
On 16.10.2007, at 15:09, Hans Moog wrote:
When it comes to interoperation between systems and or developers,
it is always a
good idea to define strict standards of how the communication
between libarys and components
has to take place (since public methods are something like an
interface
>The point is that I do not see this feature at all relevant to
>solving the web problem. This is where PHP needs to focus. Namespaces
>help in solving the web problem, because it eases cooperation of
>independent developers to supply libraries. The feature you are
>proposing is solved easi
On 16.10.2007, at 13:43, Hans Moog wrote:
I agree. But PHP (until PHP 5.2.x) was the wrong language for
everyone who wanted to use namespaces, too.
But a programming language is able to evolve and sometimes new
features are really usefull and should be included. And in this
special case
>> And if you have more than one parameter you will name it
>> methodFromStringIntegerSampleClassBoolean ?!?
>
>No, I would rethink my interface.
Sometimes you need more than one parameter and even rethinking wouldn't "solve"
this requirement.
>> And how would you do the same for constructors ?!
Hans Moog wrote:
> And if you have more than one parameter you will name it
> methodFromStringIntegerSampleClassBoolean ?!?
No, I would rethink my interface.
> And how would you do the same for constructors ?!? Create a
> initWithStringIntegerSampleClassBoolean method which has to be called
> aft
-
Von: Christian Schneider [mailto:[EMAIL PROTECTED]
Gesendet: Di 16.10.2007 11:45
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Hans Moog wrote:
> When it would be:
>
> ==
> function xpath(DomDocument $arg) {
>
Hans Moog wrote:
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this->loadXML($arg->getSource(;
}
function xpath(string $arg) {
return new DomXPath($this->loadXML($arg));
}
==
ion for each behaviour (although, in this situation there isn't
> that much to be commented).
>
> -Ursprüngliche Nachricht-
> Von: Timm Friebe [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 15. Oktober 2007 20:47
> An: internals@lists.php.net
> Betreff: Re: [PH
t: Mo 15.10.2007 18:38
An: Umberto Salsi
Cc: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
> That's why I developed PHPLint, a PHP parser and validator that performs
> a static analysis of the source, ensuring the safe handling of types. In
>
Hi,
On Mon, 2007-10-15 at 20:47 +0200, "Timm Friebe" wrote:
> function xpath(DomDocument $arg) {
> return new DomXPath($arg);
> }
>
> function xpath(XmlTree $arg) {
> return new DomXPath($this->loadXML($arg->getSource(;
> }
>
> function xpath($arg) { // Untyped = d
ROTECTED]
Gesendet: Montag, 15. Oktober 2007 20:47
An: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hi,
[...]
> Later we added type hints to help code readability.
Let me jump at this:
==
function xpath($arg) {
if ($arg instanceof DomDocument) {
Hi,
[...]
Later we added type hints to help code readability.
Let me jump at this:
==
function xpath($arg) {
if ($arg instanceof DomDocument) {
return new DomXPath($arg);
} else if ($arg instanceof XmlTree) {
return new DomXPath($this->loadXML($arg->getSource()));
} else i
That's why I developed PHPLint, a PHP parser and validator that performs
a static analysis of the source, ensuring the safe handling of types. In
a word, this tool makes PHP very close to a strong-typed language without
the need to further complicate the interpreter with new features that would
pe
t;php way" - so there is still hope :P )
>
> -Ursprüngliche Nachricht-
> Von: Umberto Salsi [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 15. Oktober 2007 16:36
> An: internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
>
> Po
On 15 Oct 18:15, Hans Moog wrote:
> But since I and Richard Quadling seem to be the only ones who would like
> to have this feature in php [...]
No, you are of course not alone.
ragards dtg
--
_
ASCII ribbon campaign ( )
against HTML e-mailX
lto:[EMAIL PROTECTED]
Gesendet: Montag, 15. Oktober 2007 16:36
An: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Posting to newsgroup php.internals, Stanislav Malyshev wrote:
> > only reason to use type hints - to ensure the method is used
> >
Posting to newsgroup php.internals, Stanislav Malyshev wrote:
> > only reason to use type hints - to ensure the method is used
> > correctly and build more robust applications), it is better to tell
>
> BTW, I'm not sure how exactly it makes the code more robust - if you
> call it with wrong typ
Posting to newsgroup php.internals, you wrote:
> > But if you want to be more strict and limit the coder to use your
> > functions only with a specific parameter signature (and thats the
>
> The purpose of signature overloading in most languages isn't input type
> control, it's different functio
On 14/10/2007, Hans Moog <[EMAIL PROTECTED]> wrote:
> You are missing something. Using this new feature would be voluntarily (it is
> optional like type hints are already).
>
> If you want to code the old way and you don't want to force coders to use
> your functions correctly, you could leave ou
On 13.10.2007, at 18:46, Hans Moog wrote:
Will method overloading by method signature be implemented in php6 or
even php 5.3?
this feature isnt php .. or rather its a solution to a problem that
does not exist in php .. for good reason.
regards,
Lukas
--
PHP Internals - PHP Runtime Develo
Hello Hans,
Sunday, October 14, 2007, 1:11:35 PM, you wrote:
> I will do so, but i will have to modify it to work with the current php
> version and I wanted to know if everybody hates this way of method
> overloading first.
> Btw: We made some benchmark tests when we decided to use it. And the
Btw: We made some benchmark tests when we decided to use it. And the
method calls were about 0.1 Percent slower. But without having to
check or escape every parameter anymore it even boosts performance
If you think parameter typing would free you from having input
validation, IMHO you are on a
But if you want to be more strict and limit the coder to use your
functions only with a specific parameter signature (and thats the
The purpose of signature overloading in most languages isn't input type
control, it's different functionality on different types. However,
unlike many other langu
Hans Moog wrote:
You are missing something. Using this new feature would be
voluntarily (it is optional like type hints are already).
Thanks for bringing that up right after I told you that I won't accept
this argument ;-)
If you want to code the old way and you don't want to force coders t
Hans Moog wrote:
> Kcachegrind doesn't show the function signature in the callgraph because the
> parameter signature is not part of the function signature. If the parameter
> siganture would be moved into the function signature, kcachegrind would adept
> and show it.
>
> Btw: You don't have to
achricht-
Von: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 14. Oktober 2007 16:50
An: Christian Schneider
Cc: Marcus Boerger; internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Christian Schneider wrote:
> Marcus Boerger wrote:
>> I
14:27
An: Marcus Boerger
Cc: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Marcus Boerger wrote:
> If you have such a patch you should definitively post it here so that we
> can hve a look. Most interesting to us is however the oerformance impact
Christian Schneider wrote:
> Marcus Boerger wrote:
>> If you have such a patch you should definitively post it here so
>> that we
>> can hve a look. Most interesting to us is however the oerformance
>> impact. As
>> that was the main reason to go any further than adding return type hints.
>
> Am
Marcus Boerger wrote:
If you have such a patch you should definitively post it here so that we
can hve a look. Most interesting to us is however the oerformance impact. As
that was the main reason to go any further than adding return type hints.
Am I the only here who thinks that performance
n: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 13. Oktober 2007 22:22
> An: Hans Moog
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Method overloading by method signature
> Hans, such overloading would be incompatible with php's dynamic nature
ilto:[EMAIL PROTECTED]
Gesendet: Sonntag, 14. Oktober 2007 10:04
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
On 10/14/07, Hans Moog <[EMAIL PROTECTED]> wrote:
> It shows an error that fun1 is not implemented for the signature of the
it is better than the '$x = "defaultValue"' kind of way to accept
> > different count and types of parameters because it is MUCH more expressive
> > and intuitive.
> >
> > It wouldn't even break backward compatibility beause it is just
> > &quo
to:[EMAIL PROTECTED]
> Gesendet: Samstag, 13. Oktober 2007 22:22
> An: Hans Moog
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Method overloading by method signature
> Hans, such overloading would be incompatible with php's dynamic nature
> As far as I remember,
king the variable types manually and then dispatching to the
> right behaviour.
>
> -----Ursprüngliche Nachricht-
> Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 13. Oktober 2007 22:22
> An: Hans Moog
> Cc: internals@lists.php.net
> Betreff: Re: [
sprüngliche Nachricht-
> Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 13. Oktober 2007 22:22
> An: Hans Moog
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Method overloading by method signature
>
> Hans, such overloading would be incompatible
Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hans, such overloading would be incompatible with php's dynamic nature
As far as I remember, even type-hinting for basic-types (strings,
integers) was rejected
On 10/13/07, Hans Moog &l
Hans, such overloading would be incompatible with php's dynamic nature
As far as I remember, even type-hinting for basic-types (strings,
integers) was rejected
On 10/13/07, Hans Moog <[EMAIL PROTECTED]> wrote:
> Will method overloading by method signature be implemented in php6 or
> even php 5.3?
Will method overloading by method signature be implemented in php6 or
even php 5.3?
Example:
I think this would be a very big advantage and would help developers to
write better code.
41 matches
Mail list logo
