2011/12/4 Clint M Priest :
> Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
>
> In the end it is a relatively simple patch. The new syntax effectively
creates internal functions on the object and the system looks for those
functions and calls them at the appro
On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps wrote:
> Hi,
>
> I also find this syntax confusing and I think it has a huge WTF factor.
>
> Some thoughts about the syntax:
> - At the first glance, it isn't clear which visibility the getter or
> setter has
> - The extra indentation level makes the
etters/setters actually
compile down to two method implementations, while implemented
getters/settings do the same, substituting "value" for whatever is required
to access the auto-implemented backing field.
On Tue, Dec 6, 2011 at 9:26 AM, Will Fitch wrote:
>
> On Dec 6, 2011, at
operty zval and bitmap added to the zend_uchar type identifying it as
> an accessor I'm saying be creative - don't just implement something
> halfway for the sake of getting it done.
>
>
> On Dec 7, 2011, at 12:50 PM, Rasmus Schultz wrote:
>
> >> if w
. What are the benefits of the C codebase
over Phalanger?
I understand the licensing may be an issue. It may be the argument that
outweighs everything else, but I'm curious to hear what else would keep you
from moving to Phalanger?
Thanks!
- Rasmus Schultz
You want to compare Mono performance to .NET performance - I'm sorry, but I
don't see how that's even relevant?
Your benchmark would be relevant if I was proposing you write a PHP
interpreter and run that on Mono.
What I'm proposing (and what Phalanger does) is to compile PHP code to CLR
bytecode
Hello Folks,
We're hosting an increasing number of Drupal (ick) sites on our servers,
and while going over the diagnostic screen for APC, we noticed that
identical files are being cached multiple times.
For example, "user.module" is cached 3 times for 3 sites.
I've seen other people asking this
t to apply an
annotation. Neither approach is very elegant. This is addressed by the
language, by allowing you to import classes and interfaces - annotation
libraries could discover imported annotation types this way, but that
aspect of the source code is not exposed via Reflection.
Any thoughts?
bly more important aspects of PHP that need attention...
2012/1/29 Johannes Schlüter
> Hi,
>
>
> On Sun, 2012-01-29 at 18:51 -0500, Rasmus Schultz wrote:
> > I realized the other day that ReflectionFile is missing from the
> Reflection
> > API.
>
> As is Reflec
t needs these
feature is going to implement this feature in different ways...
2012/1/30 Johannes Schlüter
> On Mon, 2012-01-30 at 09:33 -0500, Rasmus Schultz wrote:
> > From my point of view, the concept of a "file" has become semantically
> more
> > important, an
A couple of quick comments...
Why can't the read-only and write-only keywords be implicit instead of
explicit? I've never seen another language where you have to explicitly
indicate what you're doing. At best, it acts an extra fail-safe to prevent
making errors - at worst, it just means more redun
On Sat, Feb 4, 2012 at 1:13 PM, Clint M Priest wrote:
> The read-only and write-only keywords act a little differently. Without
> them, attempting a set on an accessor without a setter defined will cause
> __set() to be called whereas with the read-only it will produce an error.
> The inverse i
Just a couple of quick notes...
I think that your proposal looks good, but I'd like to suggest a few
> changes. First of all, I'd like to see the association with integers
> removed. An enum instance shouldn't just be a name for an integer, it
> should be more like a singleton instance of a specia
I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...
What if you could resume execution after an exception was thrown?
Fictive example:
function test()
{
echo "Begin Test!\n";
throw
mething I've been thinking about deeply...
On Tue, Apr 3, 2012 at 3:28 AM, reeze wrote:
>
> If just for exception recovery how about implement ruby's retry ?
>
> http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement
> section.
>
>
> 在 2012年4月2
2012/4/5 Anthony Ferrara :
> Why not just do:
>
> function foo(callable $callback) {
> $a = 0;
> $callback();
> $a = 1;
> $callback();
> }
>
> function bar() {
> foo(function() { echo 1; });
> }
>
> It's functionally the same, but doesn't have the stack magic.
>
> Now, it won't be ab
> From: Arvids Godjuks
> To: Kris Craig
> Cc: PHP internals list , Yasuo Ohgaki
>
> Date: Fri, 13 Apr 2012 03:26:16 +0300
> Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
> Well, I just don't know how i can appeal to common sence to some people on
> the list anymore.
> On 04/10/2012 06:20 PM, Adir Kuhn wrote:
>
> "PHP Gotchas, how they came to be, and why we can't simply fix them"
>
can't or won't?
It seems that the requirement for backward compatibility, as with most
software, stands in the way of any substantial leaps, and makes it
impossible to do away wi
I agree, overloading isset() for properties is somewhat creepy - as
that would mean you can no longer rely on isset() to actually work the
way it works for any other value. I understand that's actually the
intent, but I think this would be confusing - isset() is supposed to
behave a certain way dep
On Tue, Apr 24, 2012 at 10:10 PM, Anthony Ferrara wrote:
> There's already an __isset() magic method that does exactly this:
> http://us2.php.net/manual/en/language.oop5.overloading.php#object.isset
I know.
In my opinion, that was a mistake, and if I catch anyone on my team
using that, I will ha
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
= 'a';
$foo-> = 'b';
$foo->cc
Adding/removing properties at runtime is great if you want obscure,
unmaintainable code and don't think an IDE is useful.
So to make my previous statement more precise, dynamic properties are
not widely used in respectable modern codebases, and is generally
something a reputable developer would fr
: [PHP-DEV] memory usage ouchy
On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz
wrote:
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
[snip]
The test-script contains no information about the vers
n-number comparison standard.
But as you can see, people aren't using the function as-is anyway - they're
writing their own...
- Rasmus Schultz
> 1.0.0 and 1.0 are different things.
I think the problem is, version numbers are different things to different
people - I guess the documentation maybe isn't clear enough on precisely
what version numbering scheme it's using. To most people, "1" and "1.0" are
the same thing, because they look lik
using this particular version-numbering scheme, 1.01 is equal to 1.1 - I
don't think that's a bug, because the version-numbers in this
version-numbering scheme are integers, not decimals.
so I believe this is in fact as correct as it can be, since numbers like
"01" should not really be used in thi
I was doing some work with the Reflection API, and I ran into something
missing from ReflectionParameter.
Turns out, there's no way to get the class-name of a parameter, short of
calling getClass() - the problem with that is, there's no way to get the
class-name of a parameter without causing the
Is this RFC outdated?
https://wiki.php.net/rfc/jsonable
We have JsonSerializable in 5.4 - this appears to be essentially the same thing?
(Should it be moved from "draft" to "implemented", or should it just
be removed? It was not implemented with the names used in this RFC.)
I was also looking a
Is this all the documentation there is for the use-clause for
anonymous closures?
http://us2.php.net/manual/en/functions.anonymous.php
For one, it would be nice to have documentation that explains whether
the variables listed in the use-clause are copied/referenced at
declaration-time or at call-
How come there is no straight-foward obvious way to simply remove a given
value from an array?
Just look at the number of horrible ways people solve this obvious problem:
http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key
Shouldn't we have something simple, like:
a
>
> if(($key = array_search($del_val, $messages)) !== false) {
> unset($messages[$key]);
> }
>
> Nothing horrible here.
>
I disagree - this is (or should be) a simple, atomic operation...
yet, you've got a function-call, an intermediary variable, a boolean test,
and an unset statement repeatin
ping.
And it doesn't help make codebases more legible when people come up with 25
different ways to do it.
On Fri, Aug 17, 2012 at 5:23 PM, Rasmus Lerdorf wrote:
> On 08/17/2012 05:21 PM, Rasmus Schultz wrote:
> >>
> >> if(($key = array_search($del_val, $messages)) !
gt;
> On 16.08.2012, at 0:18, Rasmus Schultz wrote:
>
> > How come there is no straight-foward obvious way to simply remove a given
> > value from an array?
>
> Well, this sounds like a reason for creating SplSet class
>
>
Absolutely, you're right. I have a tendency to get dragged into those.
I apologize.
On Fri, Aug 17, 2012 at 5:50 PM, Nikita Popov wrote:
>
> Could we please stop these pseudo-arguments?
I have a login (mindplay) but I do not have permission to post or edit
anything on the wiki...
On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch wrote:
> Please let this die until someone is serious enough to come up with an
> rfc. This has been nothing but counterproductive arguing. If someone feels
b.com/321ad9b4b8c4e1713488
On Mon, Aug 20, 2012 at 10:10 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/8/21 Rasmus Schultz :
> > I have a login (mindplay) but I do not have permission to post or edit
> > anything on the wiki...
>
> I've created RFC for this
>
> ht
>
> On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen wrote:
> I know very little about AOP and don't pretend to know a lot, but how
> would we benefit
> from directly adding it into core instead of taking the approach FLOW3 did?
as I see it, the problem with AOP in PHP is the same as with any other
r Nguyen wrote:
> That's why I thnk the extension is superior to all other solutions,
> because it doesn't require code generation in userland. Also, it will be
> possible to backtrace to the declaration of the aspects.
>
>
> 2012/8/26 Rasmus Schultz
>
>> >
&g
Having thought about this for a while, I think this is a bad idea - here's why:
$array = array(1001, 1002, 1003, 1004);
$number = $array[-1]; // => 1004
$number[-1] = 1005;
$number = $array[-1]; // =>
Obviously, the last statement must return 1005, since otherwise that
val
9:24 AM, Ferenc Kovacs wrote:
>
>
> On Fri, Aug 31, 2012 at 3:14 PM, Rasmus Schultz wrote:
>>
>> Having thought about this for a while, I think this is a bad idea - here's
>> why:
>>
>> $array = array(1001, 1002, 1003, 1004);
>>
&g
I opened this bug report 2 years ago:
https://bugs.php.net/bug.php?id=52756
Is GD still actively maintained?
If it isn't, then perhaps it's time to start thinking about switching to a
graphics library that is maintained?
Perhaps something more modern with real drawing capabilities and a better
Jannik,
Thank you - this confirms I'm not crazy, or at least it's evidence to
support that theory ;-)
It may be OS specific - perhaps the Windows and OSX binaries are built
against a different build (or configuration) of FreeType?
Or it could be specific to 32 or 64 bit builds.
I have never bui
On Fri, Sep 7, 2012 at 1:12 AM, Pierre Joye wrote:
> On Fri, Sep 7, 2012 at 3:09 AM, Rasmus Schultz wrote:
> > Jannik,
> >
> > Thank you - this confirms I'm not crazy, or at least it's evidence to
> > support that theory ;-)
> >
> > It may be
Interesting technique:
http://ayende.com/blog/158721/rule-out-the-stupid-stuff-first-select-still-ainrsquo-t-broken
I wonder if this is applicable to PHP in any way? Would stream buffers
benefit from something like this?
Perhaps not, I just thought it was interesting enough to share - it's not a
7;s explicit about what's happening.
So I'm not at all demanding this feature - I'm merely posting this for
debate.
Thanks,
Rasmus Schultz
Good point - I agree. Thanks for taking the time to think about this!
On Tue, Sep 18, 2012 at 12:22 PM, jpauli wrote:
> On Tue, Sep 18, 2012 at 5:14 PM, Amaury Bouchard
> wrote:
> > Sounds to me like aspect-oriented programming, applied to object
> construction.
> > Take a look at: https://gith
Since I was the one who started this discussion, I'd like to reply to
some of these points.
First off, let me say - as you pointed out, when the values are
unique, they are best represented
as keys... however, this of course applies only to value-types, which
isn't the problem, and not
why I start
Yeah, on that note - I've never understood what use this function is,
as it reuses object IDs... it will return the same hash for two
different objects during the same script execution - so it's unusable
as far as getting unique keys for objects... and I don't know what
else you could really use it
the manual states, "The implementation in SplObjectStorage returns the
same value as spl_object_hash()" - so I don't know how this would
really work any better than a custom implementation.
perhaps safer would be to simply implement a collection-type that
requires the classes of elements in the co
omething things that probably should be
explained in the documentation.
It's perhaps the worst case of misleading user comments to date... ;-)
On Sun, Oct 7, 2012 at 7:51 PM, Sherif Ramadan wrote:
> On Sun, Oct 7, 2012 at 7:12 PM, Rasmus Schultz wrote:
>> the manual states, "Th
This looks great, and essentially has everything I had hoped for!
My only remaining comment is on the read-only and write-only keywords...
this seems really superfluous and strange to me - the syntax (using a
hyphenated keyword) and the feature itself, is way off the grid as compared
to other lang
> There's no way to stop the developer from doing that without read-only.
Yes, there is - I don't even know why would write it that way - doesn't
seem to make much sense.
What you probably should be doing, is this:
class A {
private $seconds = 3600;
public $hours {
get() { return $this-
Just a couple of quick remarks.
Clint wrote:
> I'm not even sure that automatic backing fields are even desired, I never
felt the need to have them in C# and the only reason they were included is
because they were a part of Dennis's original proposal.
Automatic backing fields are indeed necessar
Since there's a heavy debate on the list about strong typing right now, I
just want to briefly share my point of view.
PHP is not and won't be a strongly typed language. What it can be (and is
on the way to be, with Clint's work) is a language that supports
type-checking. Not the same as strongly
I second getting rid of write-onle - the only real case I can think of, is
something like a password property on a user/account model-type, which gets
encrypted and thus can't be read, and as Amaury pointed out, that should be
a setPassword() method instead, perhaps even a separate UserPasswordServ
Isn't this need basically covered by accessors?
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
- Rasmus
On Sat, Dec 1, 2012 at 7:53 PM, wrote:
> From: Sebastian Krebs
> To: PHP internals list
> Cc:
> Date: Sat, 1 Dec 2012 13:34:58 +0100
> Subject: Abstract properties
> Hi,
>
>
ry.
I would be happy to involve myself deeper in this, if others agree and
would like to work on a new RFC.
- Rasmus Schultz
I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? Virtually
every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?
e.g. thinking of concrete possible
To summarize:
A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API, and
already goes as deep as it needs to - going beyond simply finding and
extracting the docblocks would make little sense, as every annotation
lib
I'm going to address these question in the proposal I'm working on - once
it's all in writing, I will post for debate.
On Wed, Jan 9, 2013 at 2:57 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> - Should we support nested annotations?
>
> - How [Foo()] will be different from n
r
features such as annotations in a better way?
I love annotations. But I love my implementation of annotations, I probably
won't like yours, and that's not necessarily something we should need to
agree upon.
Is it really the responsibility of the language to deliver high-level
features that support patterns?
Or should it deliver simpler features that support the implementation of
those patterns?
- Rasmus Schultz
13 at 1:00 PM, Nikita Popov wrote:
> On Sat, Jan 12, 2013 at 5:29 PM, Rasmus Schultz wrote:
>
>> I hear a lot of interesting arguments in this big annotation discussion,
>> and now there's the ongoing vision discussion, which got me thinking.
>>
>> It is true that
this problem - minus e.g. resources, but
you could put your resources in an object and address that (very exotic)
need.
Bottom line, I'm not in favor of this idea - it just doesn't seem necessary
or really even beneficial to me.
- Rasmus Schultz
gt; Relax. It hasn't even been proposed yet. Give the author some time to
>> finish the RFC before proposing it here, and then we can discuss it...
>>
>> Anthony
>>
>>
>> On Tue, Jan 29, 2013 at 8:03 AM, Rasmus Schultz
>> wrote:
>>
>> &g
This is a not a feature request, just a note on something that occurred to
me.
Since there is talk of native support for annotations again, it occurred to
me that part of the problem that every userland implementation and proposed
syntax deals with, along with native implementations in other langu
I've been thinking about this RCF for a while now:
https://wiki.php.net/rfc/trailing-comma-function-args
It just doesn't seem necessary - the only time I've ever found something
like this to be necessary, is when a function takes closures or other very
long arguments, some of which are optional..
function - having a more distinct
syntax might be better.
But those things aside, what do you think about having a way to statically
reference types and members?
Thanks,
Rasmus Schultz
eference; // => ClassReference
$user_reflection_again = $user_ref->reflection; // => ReflectionClass
Same goes for property-references and ReflectionProperty, and
method-references and ReflectionMethod.
I could see this being really useful and powerful in view-engines,
object/relati
f having to know which
value-type is represented by an array, typically relying on static
helper-methods to modify their properties, and with no chance of any IDE
support.
Just putting that on the table...
- Rasmus Schultz
Is it a really big feature if it's just syntactic sugar and internally
stored as an array? say:
struct Color
{
public $r = 1.0;
public $g = 1.0;
public $b = 1.0;
}
Stored internally this might be something like:
array('__type'=>'Color', 'r'=>1.0, 'g'=>1.0, 'b'=>1.0)
Have you worked
You're right, struct isn't the right word - "value" is probably more
accurate.
value Color
{
public $r = 1.0;
public $g = 1.0;
public $b = 1.0;
public function __construct($r, $g, $b)
{
$this->r = $r;
$this->g = $g;
$this->b = $b;
}
public func
n don't change it, and you have your value type
> that is immutable.
> > > It just requires a bit self control.
> >
> > On 04 April 2013 23:59, Rasmus Schultz wrote:
> >
> > You're right, struct isn't the right word - "value" is probably
e it's a lot more complex than it sounds, but probably simpler than
attempting to "extend" arrays into structs or trying to "hide" the struct
type-name in an internal array property somehow. Being able to juggle the
types by accessing a reserved key might actually be a benef
> On the other hand, I would just use an array. (without any "magic"
> like methods on structs, yes you would have to write plain functions
> and not use OOP like methods).
Yeah, that's what people are doing right now - the problem with that, is
you have the class-name referenced on every call, e.
> why not make struct almost like a class except
> that $this is a copy (on write) - modifying and returning $this would
> be a new instance of that struct/class. That would give you
> public/private/static/variables/methods/interfaces/..., but it would
> lead to another type.
As said, I don't kno
This is all kinds of wrong:
http://3v4l.org/UZFME
So the order in which the properties were defined is the magic that makes
this work.
Wow. WTF?
Do I need to explain in detail why this is all kinds of effed up?
- Rasmus Schultz
Frankly, a magic method sounds like a much better solution than
auto-magically converting objects to arrays.
The problem with automatic conversion, is that the order of properties is
an implementation detail - the vsprintf() example perfectly illustrates the
problem:
class User
{
public $firs
s two birds with one stone - a static way to
reference properties, but with the addition of providing the actual
object-context. And the shortest possible syntax.
What do you think?
- Rasmus Schultz
pular
meta-programming techniques could be simplified and made more elegant,
easier to understand without having to learn conventions, faster to use,
and with support for static analysis.
- Rasmus Schultz
On Thu, Apr 25, 2013 at 9:22 AM, Nikita Popov wrote:
> On Thu, Apr 25, 2013 at 2:47 PM, Ra
; Am 25.04.2013 um 14:47 schrieb Rasmus Schultz :
> [...]
> >
> > What do you think?
>
>
> I'm not sure about the operator character but the general idea is a good
> one. Do you have a patch as a POC?
>
> cu,
> Lars
for.
>
>
Would you care to elaborate? What is evil about the thing I've described?
On Tue, Apr 30, 2013 at 3:58 AM, Michael Wallner wrote:
> On 30 April 2013 01:45, Rasmus Schultz wrote:
>
>> The characters was an arbitrary choice, just for the sake of argument.
>>
&
x27;
var_dump(^$user->name); // => PropertyReference(class: 'User',
propertyName: 'name', object:User(...))
$foo = ^$user->name;
var_dump($foo->getValue()); // => 'Rasmus'
$foo->setValue('Bob');
var_dump($user->name); // => &
I don't think that's necessary - the point of being able to do this, is to
apply meta-programming techniques, so in most situations, what matters is
the ability to quickly create object/property-references... using them will
usually happen inside some service component, e.g. a form-helper or
object
Any PHP dev who works with a mainstream framework does this daily, but the
frameworks rely on strings for property-names.
Take this example from the Symfony manual, for example:
class Task
{
protected $task;
protected $dueDate;
public functio
I suggested something similar earlier:
http://marc.info/?t=13632784962&r=1&w=2
However, I withdrew that idea, because I came to the realization that, for
practical applications, you usually need the object-context coupled with
the member-reference to do anything really useful.
A form-input a
I've already demonstrated and explained what's wrong with strings.
"Weird indirection" is what we have in every mainstream framework right
now, where properties can be referenced only as strings - I gave a
real-world example of this, and demonstrated with a practical example how
the proposed featu
On Tue, Apr 30, 2013 at 7:34 PM, Adam Harvey wrote:
> I would caution against generalising use cases. Personally, ::class is
> something I can use multiple times a day. This I'm not so sure about.
>
> Your use case is not my use case, and vice versa. :)
>
What is your use-case then? DI perhaps?
, 2013 at 7:50 PM, Sebastian Krebs wrote:
>
>
>
> 2013/5/1 Rasmus Schultz
>
>> Any PHP dev who works with a mainstream framework does this daily, but the
>> frameworks rely on strings for property-names.
>>
>> Take this example from the Symfony manual, for e
id syntax? I don't know.
I also figured the ambiguity with a bitwise operator is minimal damage -
bitwise operators are not one of the most commonly used features in
high-level languages.
If the asterisk (or some other character) offers and easier implementation
path, whatever.
On Tue, A
>
> This won't work, because Task::$task is a protected property
It will work for code that's properly documented with @property annotations.
On Wed, May 1, 2013 at 7:05 AM, Jannik Zschiesche wrote:
> Hi,
>
> Lazare Inepologlou
> Mittwoch, 1. Mai 2013 10:55
> Hello,
>
> 2013/5/1 Stas Malys
192bd3db84ddaf84c83
Someone said they didn't think this would work for accessors, so I'm
including a running sample with a User model that uses accessors:
http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd8e73ff80717f3cb
Note that the dynamic User::$name property in this example is prop
May 1, 2013 at 8:41 AM, Peter Lind wrote:
>
> On 1 May 2013 14:35, Rasmus Schultz wrote:
>
>> >
>> > This is a fringe feature, as evidenced by the fact that you
>> > are having a hard time convincing people that it is needed
>>
>>
>> As wit
pler,
stronger abstractions that provide more comfort and safety in an IDE.
On Wed, May 1, 2013 at 10:24 AM, Etienne Kneuss wrote:
>
>
>
> On Wed, May 1, 2013 at 2:35 PM, Rasmus Schultz wrote:
>
>> >
>> > This is a fringe feature, as evidenced by the fact t
Hi Mike,
Missed your e-mail because it went to the list only.
What you're demonstrating here is functionally equivalent to the simple
example I provided. (The example was intended to show how this feature
works, not necessarily how you would use it in practice.)
The key difference, is that a nat
eral references to anything.
Forget the whole thing.
I'm going to build every app in Drupal from now on, where everything is a
string or an array or a stdClass - at least then there's consistently no
checkable literals or IDE support for anything.
Awesome.
On Wed, May 1, 2013 a
factoring functionalities to a certain extend.
>
> -Ursprüngliche Nachricht-
> Von: ekne...@gmail.com [mailto:ekne...@gmail.com] Im Auftrag von Etienne
> Kneuss
> Gesendet: Mittwoch, 1. Mai 2013 22:12
> An: Rasmus Schultz
> Cc: Rasmus Lerdorf; Stas Malyshev; PHP internals
> Betr
pertyReference then it doesn’t matter if you use your syntax:***
> *
>
> ** **
>
> ^$user->name;
>
> ** **
>
> or
>
> ** **
>
> new PropertyReference($user, 'name');
>
> ** **
>
> because it is the same in a static analysis p
for more
static features in the language is to hold back a natural development that
is already happening whether you approve of it or not.
Maybe this particular feature is wrong for other reasons, I don't know,
that's why we're discussing it.
But don't reject the idea because it&
an facilitate complex architecture as well as simple forums and blogs?
You've made strides these past few years, you really have. Please don't
quit or think you're all done? :-)
On Thu, May 2, 2013 at 10:33 AM, Rasmus Schultz wrote:
> "authors[0].personalDetails[firstName]
nance of PHP core code etc.? Why
> not leave it to the IDE developers and performance loss is only occurring
> during development time. In my opinion this is the better choice, since PHP
> lacks a lot of static type enforcements, it is a dynamically typed language
> respectively. I
1 - 100 of 272 matches
Mail list logo
