hello!
Jani Taskinen wrote:
Nice to hear some work is done but I get very annoyed every time I see
the words "behind the scenes" (or something alike). I guess it was
because it's impossible to discuss anything on internals without the
noise coming from "outside"..? Could we finally make this lis
Jeff Moore wrote:
I don't think properties are the appropriate level to specify namespace
based access modifiers. I do think that a coarse-grained access
restriction on a class by class basis might be.
Perhaps you are right, but I was using that as an example. I actually
see great value in
Hello Ralph,
I don't think properties are the appropriate level to specify
namespace based access modifiers. I do think that a coarse-grained
access restriction on a class by class basis might be.
public class Foo {} // Default
private class Foo {}
(protected is meaningless because there i
Would this not do the same thing and perhaps be easier to implement:
namespace Foo;
protected $var;
class Bar {
}
thus allowing use of private public protected before variables, and hell
why not classes aswell.
private = only methods, code, classes in namespace Foo have access
protected = o
Since everyone is in the "namespace" frame of mind, is there a
possibility of a "namespace" access modifier?
The way I envision this working is that if for example:
namespace Foo;
class Bar {
nsprotected $_someProperty = null;
}
(or some other equivalent grammer)
Would allow the property F
> > Just a quick idea - what if requiring that autoloaders behave
> > deterministically, that is, once a certain autoloader
> > implementation
> > has been given the possibility to find a class it will
> > never be asked
> > again (because it wouldn't find it later on either).
>
> I'm not s
Nice to hear some work is done but I get very annoyed every time I see
the words "behind the scenes" (or something alike). I guess it was
It is much more efficient to communicate in person (preferably
physically, but can be phone, IM, chat, etc.) than to write
semi-anonymous mails to public li
Just a quick idea - what if requiring that autoloaders behave
deterministically, that is, once a certain autoloader implementation
has been given the possibility to find a class it will never be asked
again (because it wouldn't find it later on either).
I'm not sure if it's a correct assumption
Jani Taskinen wrote:
> Nice to hear some work is done but I get very annoyed every time I see
> the words "behind the scenes" (or something alike). I guess it was
> because it's impossible to discuss anything on internals without the
> noise coming from "outside"..? Could we finally make this list
Nathan Rixham wrote:
> Hate to bring this one up; I'll be brief!
>
> for instance smarty get's upgraded and has it's own namespace, I have a
> class which extends it, soon to be in my applications namespace which
> implements an interface in my interfaces namespace.. how does one extend
> a class
Scratch that, took the time to test myself..
namespace core; {
class base {
protected function __construct() {
}
}
class core extends core::base{
protected function __construct() {
}
}
}
namespace
On Dec 12, 2007 10:33 AM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 20.11.2007 21:57, Daniel P. Brown wrote:
> > Assisting with maintenance of the php.net site, documentation,
> > and bug fixes, as well as further developing the runtime and
> > including bundled packages (perhaps such as the TT
On 20.11.2007 21:57, Daniel P. Brown wrote:
> Assisting with maintenance of the php.net site, documentation,
> and bug fixes, as well as further developing the runtime and
> including bundled packages (perhaps such as the TTS bindings
> we created during the spring).
Usually we don't give CVS a
On 20 November I finally sent a request for a PHP CVS account
(danbrown), but still haven't received any acknowledgment. However, I
realized that I was having problems with my email intermittently, with
some messages not routing through properly. Does anyone here know how
I could check on the
Hi,
On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:
> Hi,
>
> I've been furiously working behind the scenes with Stas and Dmitry, and
> have some enhancements to namespaces in the form of 2 patches.
>
> 1) multiple namespaces per file
> 2) use ::name;
>
> 1) multiple namespaces per fil
On Tue, 2007-12-11 at 22:33 -0600, Gregory Beaver wrote:
> Any brackets adds another set of shift/reduce to the parser, regardless
> of how the syntax of the language is defined.
That's not all with that syntax.
Leads to a delayed declaration which is done at run-time, not at
compile-time - th
Hate to bring this one up; I'll be brief!
for instance smarty get's upgraded and has it's own namespace, I have a
class which extends it, soon to be in my applications namespace which
implements an interface in my interfaces namespace.. how does one extend
a class in another namespace and inde
On 12/12/2007, Nathan Rixham <[EMAIL PROTECTED]> wrote:
> > if their income depends on it, hmm, I wonder, why the hell are they
> > only complaining?
> point well made
>
> > always been open and we have always gladly given account to
> > people who contributed.
> and it's been well noticed, not
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> If the class for which autoloaded request is issued *exists*.
> However, we are discussing the case where this class *does
> not exist*, so it can not be loaded. Thus, autoload request
> will be repeat
> if their income depends on it, hmm, I wonder, why the hell are they
> only complaining?
point well made
> always been open and we have always gladly given account to
> people who contributed.
and it's been well noticed, not to mention the amount of times you have
to repeat yourself. Particular
Hello Nathan,
if their income depends on it, hmm, I wonder, why the hell are they only
complaining? The amount of people being constructive and not actual
developers with a php.net account is close to zero. That is what Jani had in
mind. We have always been open and we have always gladly given a
Surely the noise coming from outside are people's valid opinions? I mean
it's the people making the noise who have to live with decisions made on
the internals list, on a daily basis, and for most there income depends
on it.
It's not just php you're discussing, it's thousands of developers
wo
Nice to hear some work is done but I get very annoyed every time I see
the words "behind the scenes" (or something alike). I guess it was
because it's impossible to discuss anything on internals without the
noise coming from "outside"..? Could we finally make this list read-only
for every one but t
23 matches
Mail list logo
