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 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));
}
==
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
>
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));
}
==
(since when meth
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
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
As long as you only got one method per name it doesn't change things, so it
wouldn't brake backward compatibility and old functions would still behave like
expected (so it is not incompatible).
But if you want to be more strict and limit the coder to use your functions
only with a specific para
Hello Hans,
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.
marcus
Saturday, October 13, 2007, 10:47:23 PM, you wrote:
Why would it be incompatible with php's dynamic nature? (I already heard many
people saying "that this is not the php way") But why ? Don't you like it or do
you think it is just not possible to be implemented in php?
I could provide a patch that makes it possible (even with complete visibility
27 matches
Mail list logo
