ecfrac($dec_string); // returns string "1/4"
>
> I've used php for years, came accross the need for this today and was
> suprised such a basic command wasn't there.. currently the only way I
> can see to do it would be to eval.. which isn't the most secure meth
applications
> * by default, phar archives require the phar extension to run
> * massive modification of php applications required to run them as a
> phar archive
> * no caching of phar files in opcode caches
> * has write support in the extension
>
--
Mike <[EMAIL PROTECTED
php as a language. If something does not
> damage the language but will offer benefits for a broad user base, as well
> as existing code, then let it be. I for one will change every line of code I
> have that uses the Array() syntax for the shorter, more WIDELY readable []
> syntax.
>
> M
, 0644);
>From what I can tell. Although I don't know where to look to see if it
persists, but I am thinking it is safe to assume every error that
occurs triggers this php_log_err() function... any help is
appreciated.
Thanks,
mike
--
PHP Internals - PHP Runtime Development Mailing Lis
anyone?
On 8/4/08, mike <[EMAIL PROTECTED]> wrote:
> I'm curious as to how error_log is opened...
>
> Is it opened when an error occurs, as in open/append to, or is the
> file handle kept open when the PHP fastcgi process is spawned?
>
> Essentially I want to be able
On 8/5/08, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> Default is to use the sapi's logging mechanism, for example when using
> the apache module apache writes it to it'S error log in whatever way
> Apache does that (I think open on server start and then write..)
>
> Else it either uses the sys
On Thu, Sep 18, 2008 at 7:47 AM, marius popa <[EMAIL PROTECTED]> wrote:
> I was looking at the examples used in php.js library
> http://phpjs.org/functions/index
> and it struck me that is cleaner to read the functions and code without the
> $ names in it
>
> From what i understand $ in front of v
Thu, Sep 18, 2008 at 11:52 AM, Michael Wallner <[EMAIL PROTECTED]> wrote:
> Would you mind using your full name or something else? Thanks :)
> Not that I'd have a (tm) on mike, but anyway...
i have to give props to you having [EMAIL PROTECTED], but as of right now i
am not
On Fri, Sep 19, 2008 at 1:50 AM, Hannes Magnusson
<[EMAIL PROTECTED]> wrote:
> I totally agree. Its really annoying needing to type $ all the time,
> not to mention how hard it is on Norwegian keyboards. Lets replace it
> with £ !
can we make PHP whitespace dependent too? might as well. :)
not
In the meantime shouldn't this be posted on php.net?
Uninformed people are thinking that 5.2.7 is good to go.
On Sun, Dec 7, 2008 at 10:16 AM, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> I will be re-branching 5.2.7 with this revert for the purpose of 5.2.8 this
> week. This will allow the norm
Mon, Dec 8, 2008 at 1:40 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> the drop was planned for 6.0 for a reason.
> i also do not think we need to make a 5.3 release just for this.
> lets focus on getting feedback on namespaces and the other changes and have
> this fixed on beta1 early 2009
Fri, Dec 12, 2008 at 7:50 PM, Scott MacVicar wrote:
> The problem here is that none of the other JSON parsers in any other
> language support this and more importantly the browsers [2] which are now
> adding native JSON support. Users are frequently expecting the result from a
> json_encode in P
Sorry for top posting. I see no reason why php should not interop with
javascript 100% as it should. I do not see a reason to create new
functions, parameters, etc. The existing should be expected to both
encode and decode json with javascript properly. If there is a
mismatch right now, the
,
this thread reminded me of that which is why I wanted to voice off.
Thanks for the clarification (and thank you so much for PHP :))
On Dec 13, 2008, at 10:39 PM, Rasmus Lerdorf wrote:
mike wrote:
Sorry for top posting. I see no reason why php should not interop
with
javascript 100% as
ke that in the future.
On Dec 13, 2008, at 10:52 PM, Rasmus Lerdorf wrote:
Yes, but that would be going to a json_parse thing somewhere, not pure
Javascript.
-Rasmus
mike wrote:
I can't give specifics (I'm mobile and I don't remember where the
code
would be anyway) but we
On Sun, Dec 14, 2008 at 12:39 AM, Rasmus Lerdorf wrote:
> Eh? Read what you wrote there. If json wasn't pure javascript, how in
> the world would eval() work on it?
Sorry. I guess I meant it didn't execute by itself, but needed to be
interpreted using something like eval and/or thrown into a v
On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf wrote:
> 1. Document the fact that if you want to strictly conform to the JSON
> spec and be sure your json_encode output will work in various JSON
> parsers, you have to pass it a PHP array or object.
Instead of json_encode(34) the suggestion
On Mon, Dec 15, 2008 at 12:55 PM, Uwe Schindler wrote:
> As is noted in an earlier mail, I would prefer 1 (simply document it in the
> function description). In my opinion, if somebody then passes a basic type
> to json_encode he is aware of what he is doing (hopefully).
>
> For compatibility with
On Mon, Dec 15, 2008 at 1:10 PM, troels knak-nielsen wrote:
> I, for one, think that the only sane choices are 1 or 2. The third
> option is way too magic, and will end up confusing people.
In that case I would have to go for #2.
Personally I want to see PHP be as standards-compliant and compat
On Mon, Dec 15, 2008 at 1:43 PM, John Carter -X (johncart - PolicyApp
Ltd at Cisco) wrote:
> How about a strict mode added to the list of the current json_encode()
> options?
>
> That way current code will continue to work and anyone reading the docs
> will know the default behaviour isn't strictl
On Mon, Dec 15, 2008 at 8:58 PM, Mark Karpeles wrote:
> I believe part of the job should be the programmer's job too.
I'm a programmer. I expect json_* functions to encode and decode to
JSON specifications. Not PHP's original interpretation of it...
> Lazy mode is "not that good", as it's going
There's some discussion going on -discuss about whether or not to
close PHP tags.
The Zend Framework says to not use them...
http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html#coding-standard.php-file-formatting.general
Is there any opinion from the internals/PHP experts
xists('foo')) {
function foo() {}
}
Is this a very expensive thing to do? There would be a good number of
functions that would be leveraging this. Is it a no-no? or is it
pretty cheap?
Thanks
- mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
Have you looked into gearman?
http://gearman.org
On Wed, Mar 18, 2009 at 9:29 PM, Cesar D. Rodas wrote:
> Hello folk,
>
> Let me introduce myself, my name is Cesar Rodas, a young guy from
> Paraguay who wants to propose an idea for the GSoC2009.
>
> The purpose of this project is to implement
On Wed, Mar 18, 2009 at 10:06 PM, Cesar D. Rodas wrote:
> Hey mike,
> It is different, my idea is that the worker execute PHP code (I will
> embed PHP into C or C++), AFAIK gearman execute C code. The main
> advantage is that you can "deploy" your app. without recompile yo
On Wed, Mar 18, 2009 at 10:55 PM, Cesar D. Rodas wrote:
> In the presentation with Gearman you have a C extension for PHP, and
> you code the daemon itself in PHP. My idea it's different. Let's put
> it simple. I am planning code a server (similar to a web server,
> Apache) written in C or C++ th
good
results quickly, but ended up switching due to the lack of whitespace
support.
Cheers
--
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
help?? Im completely stuck
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wez Furlong wrote:
are now available via snaps.php.net.
Thanks to Edin for helping iron out this part of the build!
--Wez.
I noticed that win32std is missing, could someone add it please?
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Hello,
I'm writing this as an author and maintainer of a framework and many
> libraries.
> Caveat, for those who aren't already aware: I work for Zend, and report to
> Zeev.
> If you feel that will make my points impartial, please feel free to stop
> reading, but I do think my points on STH bear s
On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon
wrote:
> Good day!
>
> https://wiki.php.net/rfc/anonymous_classes
>
> There's a little RFC + patch that Joe Watkins put together, and as
> before with the ArrayOf RFC, I'll be helping out.
>
> So, lets get this discussion rolling.
>
> It was declin
re that Zeev is dismissing it so much as that he does not agree
with it and therefore he is doing his best to find an alternative that
remains within his vision of the PHP landscape. That is why we have
multiple options on the table at this point.
Regards,
Mike
Anthony,
On Thu, Feb 26, 2015 at 1:29 PM, Anthony Ferrara
wrote:
> Mike,
>
> One point of clarification:
>
> > This is true, however, the types that you are receiving back form a
> > multitude of data sources might be in a mixed format (databases for
> example
>
Zeev,
On Thu, Feb 26, 2015 at 2:18 PM, Zeev Suraski wrote:
> > -Original Message-
> > From: Mike Willbanks [mailto:pen...@gmail.com]
> > Sent: Thursday, February 26, 2015 9:46 PM
> > To: Anthony Ferrara
> > Cc: Dan Ackroyd; Zeev Suraski; Theodore
On Thu, Feb 26, 2015 at 3:15 PM, Zeev Suraski wrote:
> > -Original Message-
> > From: Mike Willbanks [mailto:pen...@gmail.com]
> > Sent: Thursday, February 26, 2015 10:43 PM
> > To: Zeev Suraski
> > Cc: PHP Internals
> > Subject: Re: [PHP-DEV] A diffe
On Tue, Mar 3, 2015 at 11:10 AM, Adrian Parker <
i.am.hidden.somewh...@gmail.com> wrote:
> Seeing it makes me vomit, IMHO.
>
Seeing $var = [] makes me vomit, IMHO.
>
> This is just a proposal, I know next to nothing about core PHP development.
>
On a serious note, this would never happen. The
Hi Mike,
On Mon, Mar 9, 2015 at 7:45 AM, Michael Wallner wrote:
> Hi, I’d like to start vote on RFC:continue_ob — any objections?
>
> https://wiki.php.net/rfc/continue_ob <https://wiki.php.net/rfc/continue_ob
> >
>
>
I think it would be good to put an example of why thi
Hope everyone is having a good weekend, just making sure my outbound emails are
registering on the list :)
--
Mike Dugan
m...@dugan.io
http://dugan.io
On Sun, Mar 15, 2015 at 10:07 PM, Yasuo Ohgaki wrote:
> Hi Netroby,
>
> On Mon, Mar 16, 2015 at 12:03 PM, Netroby wrote:
>
> > Does the "in" support this kind of php code ?
> >
> > ```php
> > > $arr = ['a', 'b', 'c'];
> > for ($v in $arr) {
> > echo $v;
> > }
> >
> >
> > ```
> >
> > I know
On Mon, Mar 16, 2015 at 2:12 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz
> wrote:
>
> > Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
> > > lib.php
> > > > >declare(strict_types = 1);
> > >function add(int $a, int $b) {
> > >
) where as it may mean PHP_TYPE_* as initial feedback on the
idea showed that it would be the most generalist approach and might be
useful in that context.
Regards,
Mike
ere is this:
https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF
-Mike
a build working on their machine for
local development.
And finally, one other (IMO) HUGE benefit of switching to Zig would be that it
would likely be easier for new people to onboard to contributing to the PHP
codebase than if PHP sticks with C or especially if PHP were to instead move to
> On Aug 14, 2024, at 5:27 PM, Lanre wrote:
>
>> On Wed, Aug 14, 2024 at 2:32 PM Mike Schinkel wrote:
>> > On Aug 14, 2024, at 3:05 PM, Arvids Godjuks
>> > wrote:
>> > PHP has C as core and has allowed C++ for extensions. Expanding that
>> > su
s for the response. It was exactly a (custom) autoloader situation which
> caused me to start wondering about this.
Seems Juliette's use-case may be at least somewhat similar to mine.
-Mike
ally like
> another class.
>
> When dealing with state, it's nice to have a human readable const to
> represent that state, but I always feel like they should be grouped
> together.
Yes, I would very much like that.
-Mike
P.S. See related: https://externals.io/message/107995
<https://externals.io/message/107995>
> On Aug 12, 2024, at 4:25 PM, Rowan Tommins [IMSoP]
> wrote:
>
> On 12/08/2024 17:37, Mike Schinkel wrote:
>> A really standout paragraph from that link is:
>>
>> "IMO, the whole situation is a shame. Unicode should be
>> in the stdlib of every langu
> On Aug 16, 2024, at 3:36 PM, Rowan Tommins [IMSoP]
> wrote:
> On 16 August 2024 19:44:22 BST, Mike Schinkel wrote:
>> Let me see if I understand your argument correctly? You are asserting that
>> Unicode is "too complex" to be handled in the standard librar
st discussing on the list — enable comments
made in the forum a place to be captured and converted into text and
implementation visible for everyone to see, and really motivated people can
even submit PRs to your RFC in order to spread the load of writing a good RFC.
#jmtcw #fwiw
-Mike
at get immediately
thrown away, and also cut down on memory fragmentation/garbage collector churn.
-Mike
[1]
https://github.com/php/php-src/blob/18d41502da0da1bb3928e60c41f1b821974c2c01/Zend/zend_builtin_functions.c#L1371
> On Aug 16, 2024, at 7:13 AM, Christoph M. Becker wrote:
>
> On Aug 16, 2024, at 8:02 PM, Rowan Tommins [IMSoP]
> wrote:
> On 17 August 2024 00:25:13 BST, Mike Schinkel wrote:
>> I am not sure I agree with you that adding Unicode support is the wrong
>> angle, per se.
>>
>> A strong argument could be made that Unico
Hi Juliette,
> On Aug 16, 2024, at 9:25 PM, Juliette Reinders Folmer
> wrote:
>
> On 17-8-2024 2:00, Mike Schinkel wrote:
>> To everyone on this thread and thus nobody in specific (hence my top post):
>>
>> Given that get_declared_*() populates a new ZEND_HASH
dFiles[$className] = $path;
}
});
include($path);
spl_autoload_callback($prior_callback);
return self::$loadedClasses[$path];
}
>> This approach would be a less disruptive than my prior suggestion
> Not so sure about that considering the above ;-)
Well then I think a single new function would be very low on the disruption
scale, no?
> This probably needs some more bike shedding ;-)
Shedding of bike undertaken. :-)
-Mike
> On Aug 18, 2024, at 4:59 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On 18 August 2024 05:46:09 BST, Mike Schinkel wrote:
>> I know that those functions can be called as a function and return a value
>> like the following:
>>
>> $return_value = include($pat
ut
a few `.php.config` files during CI/CD than to update all files.
Additionally PHP could use an environment variable as prescribed by 12 Factor
apps to identify the root config file. That way a hosting company could allow
someone to configure their production server to point to
`.php.productio
ame. Type aliases are super useful in practice in other languages, with many
used for single-file scope in my experience.
-Mike
> On Aug 20, 2024, at 9:44 AM, Arnaud Le Blanc wrote:
>
> Hi Mike,
>
> On Tue, Aug 20, 2024 at 2:45 AM Mike Schinkel wrote:
>> It seems Java-style Generics are viewed as the proper archetype for Generics
>> in PHP? I would challenge the wisdom of takin
n" by now; but "unqualified means
> global" feels much more achievable from where we are.
>
If I had a time machine I would campaign for real packages instead of what
namespaces turned out to me, and that used sigils that do not double as the
escape character for strings, but then both of us digress.
-Mike
Hi Rowan,
> On Aug 23, 2024, at 2:39 AM, Rowan Tommins [IMSoP]
> wrote:
> On 23 August 2024 00:15:19 BST, Mike Schinkel wrote:
>> Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR PREFERABLE
>> to _\strlen() because at least it provides satiating informatio
's 3rd option has wings. And along with
automatic `use` statements for each namespace might just be the best possible
solution.
-Mike
P.S. If PHP ever added a set of standard library functions written in PHP to
the core distribution, they should rightly IMO need to be namespaced, per this
> On Aug 23, 2024, at 7:50 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 23 Aug 2024, at 12:29, Mike Schinkel wrote:
>> namespace \AcmeComponents\SplineReticulator\Utilities\Text
>>
>> function Foo():int {
>> return Text\strlen("Hello World
> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
> wrote:
> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>> And how can it occur without an explicit `use
>> AcmeComponents\SplineReticulator\Utilities\Text\Text` statement, which I
>> proposed would
> On Aug 23, 2024, at 9:07 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 23 Aug 2024, at 13:45, Mike Schinkel wrote:
>>> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
>>> wrote:
>>> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>&g
g worthwhile.
Also, whereas only discussion happens on the list, in a repo you can actually
start writing a potential implementation and crafting an eventual RFC, so it
has the potential to be more productive. Finally, the list is the gatekeeper
anyway, so if things are already decided that the list disagrees with, it still
won't pass.
So, if you feel you are a stakeholder on this idea, I'd suggest celebrating the
idea of a repo and joining the discussion there.
-Mike
P.S. As for using Reddit, I'm not as big of that as its has its own culture
that can be just a difficult to incubate ideas as here on this list.
f making built-ins special and not
require them nor locals be prefixed, and instead require global userland
functions to be prefixed.
>
-Mike
unction stuff($foo = 'bar', $baz = 'world');
>
>
>
> stuff(...[ ...($foo ? ['foo' => $foo] : []), ...($baz ? ['baz' => $baz] :
> [])]);
>
>
And you are one who complains about gotos!😲
-Mike
d change.
Where I would see this functionality to be most useful would be:
1. Modifying a default bitmapped argument to add or remove one or more bits.
2. Creating a class instance based on the default — with Wither methods() —
where I need to modify a few properties but want to keep all the rest of the
default value.
Not saying there are not other use-cases, but those other use-cases have not
(yet?) occurred to me.
-Mike
he implementation. As far as I read
> the RFC, using "default" when there is no default would lead to a
> runtime exception, but there is no way of finding out if there is a
> default if you do not already know. Being able to test that could be
> useful, although I am not sure about the syntax for that.
Great catch!
> On Aug 26, 2024, at 6:32 AM, Andreas Heigl wrote:
> I think I am missing something here. From my understanding we are *either*
> coding against the interface and then it should not be possible to use
> `default` at all as no default is set in the interface. So the fatal error is
> totally valid for me.
Maybe default value for method parameters in interfaces is something the RFC
should consider enabling?
-Mike
> On Aug 26, 2024, at 8:28 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote:
>>> You ask how a library can provide access to that default, and the answer is
>>> generally pretty trivial: define a public constant, and ref
e it is just too risky to use automated
tooling. Once bitten, twice shy.
One approach I have seen on other projects take is they retract the versions
with BC breakage and then release an update reversing the breakage.
Something to consider.
-Mike
aving
> them. I believe that would also be a better approach than traits that link
> to interfaces, which achieves not-quite the same result with more steps.
I too am all for revisiting Interface Default Methods.
Lack of interface default methods is one of the most painful missing featur
> On Sep 1, 2024, at 6:12 PM, Christoph M. Becker wrote:
>
> On 01.09.2024 at 09:16, Mike Schinkel wrote:
>
>> One of the benefits for users when software authors strictly follow SemVer
>> is that automated tooling can decide if an automatic upgrade should be safe.
>
would not address the issues you were trying to address?
Generally I am one who welcomes new feature ideas, but I fear that string
literals as object properties would break a valuable assumption that all
properties must be a valid identifier. Without that assumption I fear many
things that would become more complex.
Also there are chances such a change could break a lot of userland code that
makes that same assumption. I know from using MySQL where field names do not
need to be valid identifiers that such a "feature" complicates coding, makes
certain bugs easier to create, and often makes code less elegant (read
"uglier") that it would otherwise be.
So I am sympathetic to the desire to improve the language. However I fear this
specific change would create more pain than pleasure. Better IMO to look for
less disruptive solutions to achieve the same goals. For example, if the
Enum+Attributes approach meets your needs aside from having too much
boilerplate, maybe we could enhance PHP to have less of that boilerplate?
-Mike
P.S. I want to (again) thank those who brought us Enums as I think they are one
of the best new features PHP has added in the past decade. #fwiw
> On Sep 2, 2024, at 12:42 PM, Christoph M. Becker wrote:
>
> On 02.09.2024 at 16:51, Mike Schinkel wrote:
>
>> Generally I am one who welcomes new feature ideas, but I fear that string
>> literals as object properties would break a valuable assumption that all
>&
> On Sep 2, 2024, at 1:48 PM, Hammed Ajao wrote:
>
> Hello Mike,
>
> Thanks for reading and responding. While your enum does technically address
> some of the issues I am discussing, it does so in a very verbose and
> cumbersome way.
> - First you need the Default
AnyChars%%!@#' is not included in the array returned by
`get_class_methods()` and/or `ReflectionClass::getMethod()` which is evidence
of why procedural magic methods are at best a bandaid compared with declarative
solutions.
-Mike
gt;default` if `default` could be used in this
context.)
Anything declared to be a `datapair` type could be declared to have names that
are not valid identifiers and end with whitespace.
A declared `datapair` inner type would default to `string` but could be
declared otherwise if needed, see how I declared `Expires` as `int`. However,
it would be good if they could always just be `string` and never anything else.
By their nature, any dataset properties or variables would need to be accessed
with braces, e.g. `$this->{Content-Type}` and `${Content-Type}` or if without
quotes is not possible in the parser then by `$this->{'Content-Type'}` and
`${'Content-Type'}`
Given the above — assuming it were accepted and added as a feature to PHP — how
would this not address your use-case(s)?
Note I have no idea if the above would even be considered, but I am proposing
here to understand what alternatives may be to address your desired use-case(s).
> Good call, I should probably separate both proposals.
+1
-Mike
> On Sep 2, 2024, at 11:20 PM, HwapX wrote:
> Hello internals!
>
> I was wondering, has there been any discussion about supporting local
> constants (variables that cannot be reassigned, perhaps even function
> parameters)?
+1 from me.
-Mike
this specific history to opine — do not apply: Java/Kotlin, Swift,
Go, C/C++, Zig, and Rust (while ignoring TypeScript given its roots in JS.)
Simply put the reason for local const is to declare an immutable variable, one
whose value we know cannot change. One key reason relevant to PHP is to ensure
its value is not changed by reference by a function you are calling, but also
so that you don't accidentally change it in the same function. And here are
some more reasons elaborated:
https://stackoverflow.com/questions/622664/what-is-immutability-and-why-should-i-worry-about-it
-Mike
ou that said that.
Whatever the case, of the features that have been implemented in recent years I
find it hard to believe adding local constants would be nearly as hard as some
of those features. Certainly easier than aviz.
-Mike
> On Sep 6, 2024, at 4:47 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 6 Sep 2024, at 03:01, Mike Schinkel wrote:
>>> Block-scoping doesn't have to allow shadowing of names,
>>
>> How exactly would that work? Are you suggesting to restrict the use of
, no problem as LocalWidget === Widget
$w = new MyWidget;
doSomething($w); // This throws an error as MyWidget !== Widget
-Mike
efs was the sort of "other stuff classes do" that I was
> trying to avoid getting into right now. :-) Mainly because I can totally see
> how it's tempting, but also have no idea what it would mean from a
> type-theoretic perspective. It would only make sense if we're talking type
> DEFs, not type ALIASes.
That latter sentence is spot-on.
-Mike
ng for or against any specific syntax, just pointing out that there
are other potential options.
-Mike
> On Sep 9, 2024, at 5:35 PM, Rowan Tommins [IMSoP]
> wrote:
>
> On 09/09/2024 19:41, Mike Schinkel wrote:
>> In Go you cannot add or subtract on a typedef without casting to the
>> underlying type. I would definitely prefer that to be relaxed, but only
>> if
pe anything that passes an RFC is intuitive and well reasoned because
otherwise our governance model is flawed and maybe we need to address that
first, if so?
-Mike
[caveat] — I am aware there are likely numerous use-cases in financial,
scientific and/or related fields that could benefit from op
nts, and so
others can ignore it unless they really want to follow it.
-Mike
Hi Rowan,
This message is in reply to https://externals.io/message/125455#125496 from the
thread "bikeshed: Typed Aliases"
> On Sep 10, 2024, at 5:35 PM, Rowan Tommins [IMSoP]
> wrote:
> On 10 September 2024 19:32:19 BST, Mike Schinkel wrote:
>> BTW, why has nobody
hat actually supports what I was saying; people would gravitate to
only doing in an extension what they cannot do in PHP itself, and over time if
PHP itself improves there is reason to migrate more code to PHP.
But there can still be reasons to not allow some thing in userland. Some things
> On Sep 11, 2024, at 4:55 PM, Rowan Tommins [IMSoP]
> wrote:
> On 11 September 2024 20:12:53 BST, Mike Schinkel wrote:
>>> It also risks conflicting with a future language feature that overlaps, as
>>> happened with all native functions marked as accepting string
currently being
discussed where the ones 4[1] and 3[2] years ago were both declined.
So arguing with me about operator overloading is effectively just tilting at
windmills. If you really want userland operator overloading in PHP so badly,
propose another RFC and everyone who wants it will like
d not have their defaults exposed.
Similarly developers that do not write their code to enable operator overloads
should not be used with userland operator overloads unless they explicitly
allow it, especially as they may not have have tested code with operator
overloads.
Anyway, that is my two cents worth.
TL;DR? I argue that PHP should operator overloads but ONLY if there is a
mechanism that requires the user of expressions that call overloaded operators
to explicitly opt-in to their use.
-Mike
> On Sep 17, 2024, at 1:37 AM, Jordan LeDoux wrote:
> On Mon, Sep 16, 2024 at 9:35 PM Mike Schinkel wrote:
>
> Yes, if constraints of the nature I propose below are adopted.
>
> The biggest problem I have with operator overloads is that — once added — all
> code could pot
, I wonder if there might be scope for multiple $key parameters,
to extract values from defined positions at even lower levels, so
that, for example:
array_whatever($array, 'colour', 'orange');
would return all sub-elements addressed as $array['colour'][&#
uld be -1 for any
implementation that doesn't differentiate them in some way from
regular functions.
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE,
, this isn't a big problem.
Best,
Mike Robinson
Zeev Suraski wrote:
> Folks,
>
> We have a bit of a situation with the PEAR distro that's
> embedded in 5.0.4. It's missing the RunTest.php file, so
> PEAR doesn't install.
>
> The options we have, as fa
t would be the thing to
do. And
it's an awesome thing to do, dig in and fix some other stuff when the
opportunity
presents itself. I appreciate this _very_ much. There's still a ton of
people, myself
included, widely using PHP4.
Best Regards
Mike Robinson
--
PHP Internals - PHP
se the ugliness of what would _appear_ to be a handy feature.
I don't pack any weight on this list so if someone with a -1 on
this feature would like to kick it up to -2 I'd appreciate it.
=)
Best Regards
Mike Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
synonym would help in any way to produce good
perfoming "pre-php5" code.
Why not make PHP5 not complaining about those php4 "var" definitions at
all?
Maybe a new error level for "deprecated" keywords (and function calls)
would be helpful?
mike
--
mike peter b
allow_url_fopen is a PHP_INI_SYSTEM flag, meens you can't change it with
.htaccess
- mike
Unknown W. Brackets wrote:
Why not simply disable allow_url_fopen on your server or servers?
With it set off, you get these errors:
Warning: main() [function.main]: URL file-access is disabl
1 - 100 of 926 matches
Mail list logo
