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
And if you have more than one parameter you will name it
methodFromStringIntegerSampleClassBoolean ?!?
And how would you do the same for constructors ?!? Create a
initWithStringIntegerSampleClassBoolean method which has to be called after
object creation ?!?
-Ursprüngliche Nachricht-
It allows you to be strict when messing with types but it doesn't allow you to
overload type hinted methods ... so this is no solution to the problem of
overloading type hinted methods, is it ?
-Ursprüngliche Nachricht-
Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Gesendet: Mo 15.1
Yeah PHPLint is cool and very useful when you want to be strict. We do use it
regularly. But it doesn't enable you to overload your methods as described
because this could only be done by a native language construct or manual type
checks and dispatching.
I thought it would be a good idea to emb
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
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 use it if you don't want to.
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 out typehints an check the parameters
manually.
But if you wa
12 matches
Mail list logo
