A full implementation of type hinting is much of a challenge and better
left to a major version release. Some opcode mojo and backpatching voodoo
should be concocted to get the juice out of this fruit.
I might sound like a broken record by now, but, sorry for my never-ending
intrusions.
I'm just too much of a geek to resist the temptation of meddling into a CS
related debate.
Best Regards,
Your friendly neighborhood wannabe game developer,
Martin Alterisio
Please let me do a little explanation of the title first. Japanese is an
interesting language where context is vital to the meaning of a word.
Sayonara usually means a simple "good bye", but within a different context
can mean "we'll probably never meet again".
To understand this mail you'll have
eed this, excellent, they have an implementation which seems viable. But,
sorry, I couldn't care less about closures or anonymous functions. Anyway,
my opinion doesn't matter, I'm just one user.
Best Regards,
Martin Alterisio
2007/12/21, Greg Beaver <[EMAIL PROTECTED]>:
>
> Martin Alterisio wrote:
> > Consider the following code:
> >
> > foo.php:
> > > class test {
> > public static function foo() { echo "I'm foo in class test\n"; }
> > public sta
2007/12/22, Christian Seiler <[EMAIL PROTECTED]>:
>
>
> PPS: Oh, yeah, if it should be legally necessary, I grant the right to
> anybody to use this patch under any OSI certified license you may want
> to choose.
>
>
That's very kind of you but, if I was explained right, you don't have
copyright on
2007/12/21, Paul Biggar <[EMAIL PROTECTED]>:
>
> Hi Martin,
>
> On Dec 21, 2007 8:30 PM, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> > I've been pondering about how to algorithmically/mechanically prepare a
> non
> > namespaced code for namespaces a
teful if you share.
Best Regards,
Martin Alterisio
eryone is free to
> use it without permission, fees etc. Much like a BSD or MIT license,
> but without the additional conditions of preserving copyright notices.
>
>
>
> David
>
>
>
> Am 21.12.2007 um 14:29 schrieb Martin Alterisio:
>
> > No, public domain isn&#
blic distribution and
that the code was an in-house development. Anyway, it's too complicate and I
understand very little. To get the real facts here, you should talk to your
lawyer.
2007/12/21, Alexey Zakhlestin <[EMAIL PROTECTED]>:
>
> isn't "public domain" specif
2007/12/20, Martin Alterisio <[EMAIL PROTECTED]>:
>
> 2007/12/20, Greg Beaver <[EMAIL PROTECTED]>:
> >
> > Martin Alterisio wrote:
> > > Consider the following code:
> > >
> > > test.php:
> > > > > include &
not much of the legal
mumbo-jumbo comprehension, so, correct me if I'm wrong, shouldn't external
code that's to be included in the php codebase meet these legal formalities
so it doesn't become a liability?
That's all.
Best Regards,
Martin Alterisio
PS: Does anyone knows
through a
static reference, except when within the class scope where you can refer to
the method through self::
The static method remains partially hidden by the namespaced function.
Best Regards,
Martin Alterisio
2007/12/20, Greg Beaver <[EMAIL PROTECTED]>:
>
> Martin Alterisio wrote:
> > Consider the following code:
> >
> > test.php:
> > > include 'foo.php';
> > use test::foo;
> > foo();
> > ?>
> >
> > foo.php:
> >
Consider the following code:
test.php:
foo.php:
Is it expected behavior that the scripts ends in:
Fatal error: Call to undefined function foo()
?
That's all for now.
Best regards,
Martin Alterisio
PS: Is there any benchmark that could be run to test out what's the impact
of t
2007/12/10, Martin Alterisio <[EMAIL PROTECTED]>:
>
>
> > c) If bracketed namespaces are a no-go, consider the possibility of
> > > declaring the full name of the namespaced element in its definition:
> >
> > Which would lead to people routinely mixing differ
2007/12/10, Martin Alterisio <[EMAIL PROTECTED]>:
>
>
> > 2) Using :: as namespace separator generates ambiguity
> >
> > Would that be 20th reincarnation of "let's find weirdest namespace
> > separator" thread? :)
>
>
> Please no.
2007/12/10, Stanislav Malyshev <[EMAIL PROTECTED]>:
>
> > All namespace access should be explicit:
>
> Consequence: nobody uses namespaces, as it's too annoying.
Putting $this-> and self:: is annoying , that didn't stop anybody from using
objects in PHP.
> b) Name aliasing with use should only g
1) Lack of cohesiveness of name resolution rules
Why is this an argument against: name resolution rules with namespaces
change completely the way names are resolved in PHP.
How does it affects: this breaks the explicitness of names in PHP. It will
affect code debugging and review.
Example:
Su
2007/12/5, Keryx Web <[EMAIL PROTECTED]>:
>
> Stanislav Malyshev skrev:
> >> +1 for putting namespaces on the backburner and taking the time to
> >> get it 100% right ...
> >
> > What's "100% right"? Any proposals (besides braces)?
> >
>
> Actually I did mention an alternative a while ago, and that
2007/12/5, Jochem Maas <[EMAIL PROTECTED]>:
>
> metrics that support your argument that namespaces will make code more
> maintainable, offer better structure and cleaner code.
>
>
Metrics aren't needed. I believe the almost 5 decades of OOP languages using
some sort of classes grouping and organiza
2007/12/5, Robert Cummings <[EMAIL PROTECTED]>:
>
> On Wed, 2007-12-05 at 09:34 -0800, Stanislav Malyshev wrote:
> > > Namespace support is for people who didn't name their
> classes/functions
> > > properly.
> >
> > Here's a claim so weird I don't know how to parse it.
>
> I think you're confusing
2007/12/4, Gregory Beaver <[EMAIL PROTECTED]>:
>
> Martin,
>
> Please stop spreading misinformation.
[snip]
>
At least get your facts straight before posting.
>
> Greg
>
Greg, that was uncalled for.
Isn't it a fact that the namespace keyword does more than just declare a
namespace in your cu
2007/12/4, Chuck Hagenbuch <[EMAIL PROTECTED]>:
>
> Quoting Martin Alterisio <[EMAIL PROTECTED]>:
>
> > Knowing that I'll have to strongly encourage the developers to dump that
> > patch. The namespace declaration shouldn't do more than what it's
&
2007/12/4, Michael McGlothlin <[EMAIL PROTECTED]>:
>
>
> > Actually, it's an expected tradeoff of interpreted languages.
> > Compilable languages have both a compiler and a linker that bundles
> > everything in one executable. By using bytecode caching and bundling
> > you're just getting closer to
2007/12/4, Gregory Beaver <[EMAIL PROTECTED]>:
>
> Martin Alterisio wrote:
> > It's also not possible to reliably bundle files even if you could have
> > multiple namespaces declarations as, correct me if I'm wrong, import
> > statements affect the whol
2007/12/4, Michael McGlothlin <[EMAIL PROTECTED]>:
>
> The need to pack a program all into a single source file for performance
> reasons would seem to indicate that the way PHP compiles/interprets
> could be improved. Wouldn't it be better to improve this area than add
> language features to deal
2007/12/4, Gregory Beaver <[EMAIL PROTECTED]>:
>
> Martin Alterisio wrote:
> > 2007/12/4, Gregory Beaver <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>:
> >
> > Martin Alterisio wrote:
> > > 1) Why is performance relev
2007/12/4, Gregory Beaver <[EMAIL PROTECTED]>:
>
> Martin Alterisio wrote:
> > 1) Why is performance relevant to whether namespaces are implemented one
> per
> > file or many per file?
>
> Because there is a performance difference between code in separate files
>
2007/12/4, Roman Borschel <[EMAIL PROTECTED]>:
>
> On Dec 4, 2007, at 5:09 PM, Martin Alterisio wrote:
> > 1) Why is performance relevant to whether namespaces are implemented
> > one per
> > file or many per file?
>
> Because including/requiring 80 files on
Sorry to step in uninvited to this discussion, I have some doubts about all
this, and I'll really appreciate if someone more knowledgeable could
enlighten my ignorance. The doubts I have are as follows:
1) Why is performance relevant to whether namespaces are implemented one per
file or many per f
2007/11/17, Sam Barrow <[EMAIL PROTECTED]>:
>
> But why not have maximum flexibility? A language should provide as many
> tools to the user as possible, a tool doesn't hurt. If you don't want to
> do it, don't, who cares? But an extra tool never hurts in any situation,
> real life or a programming
The following is just an opinion from an user and should be considered as
such.
You should consider that the PEAR way of naming classes was the nasty
workaround that the namespaces is trying to solve. Therefore, just trying to
make the language fit your needs so you can still use that nasty workar
2007/10/2, Alexey Zakhlestin <[EMAIL PROTECTED]>:
>
> On 10/1/07, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> > Sorry to bother, I have a few questions on this matter.
> > How will this impact on the SPL ArrayAccess and related interfaces and
> > objects?
&g
array_slice() if used with an
ArrayAccess implementation?
Thank you and sorry for the bother.
Regards,
Martin Alterisio
2007/10/1, Alexey Zakhlestin <[EMAIL PROTECTED]>:
>
> Here http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs is a
> phrase "For both strings and arrays,
Thanks everyone!
I've just submitted the report, adding the info you provided.
Regards,
Martin Alterisio
I did as much as possible from the steps asked in the php bugs page, but
still I want to check with you folks before submitting a bug report.
I found a strange behavior in PHP 5.2.4. Try running the following code:
At the end of the script, the static var stores not the object but the
string re
36 matches
Mail list logo
