Hi!
> To get a bit philosophical: Is it really the language's job to make
> that decision? Is there a difference between "encouraging",
> "allowing", and "enabling"?
I think, yes on both. The PHP tradition is to allow doing stuff that may
look weird (most languages won't allow you to do $$foo) bu
Yes, C# documented here:
http://msdn.microsoft.com/en-us/library/79b3xss3.aspx
On Mon, Dec 1, 2014 at 5:41 PM, Levi Morrison wrote:
> Perhaps I have missed it in the noise, but have any other mainstream
> languages (or new hipster ones; I don't care) have something
> equivalent to the proposed s
Perhaps I have missed it in the noise, but have any other mainstream
languages (or new hipster ones; I don't care) have something
equivalent to the proposed static classes?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PR with this feature request: https://github.com/php/php-src/pull/929
On Mon, Dec 1, 2014 at 4:56 PM, Rowan Collins
wrote:
> On 1 December 2014 20:30:46 GMT, Andrea Faulds wrote:
> >
> > The problem is that, well, global state is rarely a good thing, I don’t
> think we should be encouraging it.
On 1 December 2014 20:30:46 GMT, Andrea Faulds wrote:
>
> The problem is that, well, global state is rarely a good thing, I don’t think
> we should be encouraging it.
To get a bit philosophical: Is it really the language's job to make that
decision? Is there a difference between "encouraging",
> On 1 Dec 2014, at 17:46, Stanislav Malyshev wrote:
>
> Hi!
>
>> (2) Add lexically-scoped variables, and allow normal global functions
>> to be closures. By this I mean we add something like JavaScript’s
>> `let` keyword that would make a variable that is unset when it falls
>> out of scope (e
Hi!
> static class Foo {
> function bar() {
> echo do_something_with($this);
> }
> }
>
> Much nicer (and just as easy) for that to give a compile-time error of
> "Static class Foo cannot contain non-static function bar" than for it to
> autoload fine, and then give a less obvious
I'm working on a patch right now and I removed the implicit configuration
of static to methods.
It's only missing reflection magic. Should be out of the oven in one hour
or less.
On Mon, Dec 1, 2014 at 2:44 PM, Lars Strojny wrote:
> Hi Guilherme, hi Robert.
>
> > On 01 Dec 2014, at 14:58, Robert
Hi Guilherme, hi Robert.
> On 01 Dec 2014, at 14:58, Robert Stoll wrote:
>
> I am not sure what makes more sense for PHP, but just as thought-provoking
> impulse, wouldn't it be better just to check that all methods are static and
> __construct private instead of turning methods magically into
Hi!
> (2) Add lexically-scoped variables, and allow normal global functions
> to be closures. By this I mean we add something like JavaScript’s
> `let` keyword that would make a variable that is unset when it falls
> out of scope (end of a {} block, end of a file etc.). Then, we allow
> normal fun
Levi Morrison wrote on 01/12/2014 17:58:
The only thing missing is a standardised, enforced, annotation on the class
to declare that you are using this ability and instances will never be
created.
Let's say a class has no members: what's the harm in instantiating it?
Sure, it logically doesn't d
Am 01.12.2014 17:37 schrieb "Rowan Collins" :
>
> guilhermebla...@gmail.com wrote on 01/12/2014 15:27:
>
>> (1) Function/Namespaced function autoloading
>> (2) State encapsulation
>> (3) Function scoping
> I would add (4) static polymorphism, which Late Static Binding explicitly
supports.
Amen!
> The only thing missing is a standardised, enforced, annotation on the class
> to declare that you are using this ability and instances will never be
> created.
Let's say a class has no members: what's the harm in instantiating it?
Sure, it logically doesn't do anything useful, but is this user e
guilhermebla...@gmail.com wrote on 01/12/2014 15:27:
(1) Function/Namespaced function autoloading
(2) State encapsulation
(3) Function scoping
I would add (4) static polymorphism, which Late Static Binding
explicitly supports.
But PHP is not one of these dogmatic “everything must be a class
> On 1 Dec 2014, at 16:12, Christoph Becker wrote:
>
> Andrea Faulds wrote:
>
>> Yes, they’re a simple addition, but I still think they’re the wrong
>> solution to the problem. We shouldn’t force people to use classes for
>> simple collections of functions. People have wanted function
>> autolo
Andrea Faulds wrote:
> Yes, they’re a simple addition, but I still think they’re the wrong
> solution to the problem. We shouldn’t force people to use classes for
> simple collections of functions. People have wanted function
> autoloading for years. I say it’s high time we add that.
Maybe
Hi!
> On 1 Dec 2014, at 15:27, guilhermebla...@gmail.com wrote:
>
> Hi Andrea,
>
> Thanks a lot for putting efforts thinking through this problem.
> Indeed we have 3 problems that leads to "static classes". You detailed 2 of
> them.
> The third is around encapsulation. I may want functions that
Hi Andrea,
Thanks a lot for putting efforts thinking through this problem.
Indeed we have 3 problems that leads to "static classes". You detailed 2 of
them.
The third is around encapsulation. I may want functions that are reused by
other functions at the namespace level, but that shouldn't be used
Hi all!
> On 1 Dec 2014, at 13:58, Robert Stoll wrote:
>
> I read your updated RFC:
> https://wiki.php.net/rfc/abstract_final_class
Hmm, I don’t like this new RFC either. Static classes in languages like C#
exist because the language designers made the dogmatic decision to require
everything
Hi Guilherme,
I read your updated RFC:
https://wiki.php.net/rfc/abstract_final_class
IMO the RFC as such makes sense now (abstract final confusion is eliminated. In
addition to turn methods implicitly into static methods, the __construct of a
static class should be implicitly private as well.
I
20 matches
Mail list logo