Hi, Rasmus! 2017-01-21 4:14 GMT-04:00 Rasmus Schultz <ras...@mindplay.dk>:
> > How hard is it to write Foo::bar? You never have to go more > than one level. I don't see a point in mixing internal function > namespace with class methods for the sake of saving typing couple of > characters. > > I'm not suggesting we mix namespaces - this of course would be file-local, > same as use-statements in general. > > You likely have to write a use-statement either way, if you're going to > call a static function, e.g.: > > use Foo\Bar\HtmlHelper; > echo HtmlHelper::escape($text); > > Versus: > > use Foo\Bar\HtmlHelper::escape; > echo escape($text); > > It's not about "saving characters", that's not what use-statements are for > - it's to avoid qualifying the same references repeatedly, which (for one) > is better for source-control, whether that's a namespace or a class-name > being repeated. > > Anyhow, it sounds like most of you are positive about this idea, so I will > ponder the details and post a small RFC :-) > > > On Jan 20, 2017 19:55, "Stanislav Malyshev" <smalys...@gmail.com> wrote: > > Hi! > > > Since the autoloading functions proposal is stalled, how about allowing > for > > import of static functions instead? > > > > use function Foo::bar; > > > > bar(); // calls Foo::bar() > > I'm not sure why it is good. This would certainly be confusing, if you > call strlen and turns out it's completely different function from what > you thought. One thing when it's the same namespace, at least you can be > aware what this package does, but if it's just an arbitrary function > from anywhere, it's really bad for understanding the code. > > How hard is it to write Foo::bar? You never have to go more > than one level. I don't see a point in mixing internal function > namespace with class methods for the sake of saving typing couple of > characters. > > -- > Stas Malyshev > smalys...@gmail.com > I think this idea looks like the easiest way to avoid fixing the underlying problem. But it would irrevocably push functions to a "second class citizenship" of the language, in favor of static classes. It also would blurry the lines between namespaces and classes in a way we haven't seen before. Even though it feels pragmatic to do so, I'd prefer the harder path or at least wait for the next major until commit to this. Thanks, Márcio.
