2017-03-12 23:01 GMT+05:00 Fleshgrinder :
> As I said already, there is no problem if you just change the direction
> of the inheritance.
>
Ok, how to inherit Rectangle, Square, Rhomb, all of which are
Parallelogram? In your example Rectangle knows restrictions of Square and
any Rectangle is inst
2017-03-12 18:54 GMT+05:00 Fleshgrinder :
>
> Post this on Stackoverflow and I'll give you some answers and possible
> approaches. ;) You are clearly struggling with architecture and design,
> but you are definitely not missing language constructs here.
>
> --
> Richard "Fleshgrinder" Fussenegger
2017-03-12 15:33 GMT+05:00 Yasuo Ohgaki :
> DbC allows this kind of validation at development time.
> I suppose you would like to check requirement at runtime always.
Yes, DbC from here https://wiki.php.net/rfc/dbc2 describes similar things.
This is good idea, but I tell more about checks which ca
2017-03-12 14:58 GMT+05:00 Fleshgrinder :
> The problem you are facing is that you are dealing with an anemic domain
> object that does not enforce its own invariants.
>
Incomlplete order with date and address not set yet is a valid state of
order.
Also, there are many cases when logic which incl
2017-03-12 14:14 GMT+05:00 Lester Caine :
> My problem here is with the reason for needing a different class for
'Square' when $rectangle->is_square() is a simple additional check on a
single Rectangle class.
Yes. And we have to call it in all operations with Square manually, and
throw exceptions
2017-03-12 13:58 GMT+05:00 Sherif Ramadan :
> I think you're trying desperately to find a problem that is fitting of
the proposal
Checks in business logic are popular task.
> If the problem you're trying to solve pertains to object state that I
have no idea how this proposal hopes to achieve tha
2017-03-12 13:03 GMT+05:00 Sherif Ramadan :
how it pertains to this discussion
>
This is example of type matching from my first message.
I'm not sure what that has to do with inheritance
>
Yes, this is not related with inheritance. But order can be ready for
checkout or can not. This is a varia
2017-03-12 12:19 GMT+05:00 Sherif Ramadan :
> Which requirements are those exactly?
>
An order should have count of products > 0 and date and address filled
before checkout procedure.
2017-03-12 12:03 GMT+05:00 Sherif Ramadan :
> You could have an abstract classes implement the interface and extend from
> the abstract classes.
>
>
Ok, could you give an example, how to check described requirements with
interface?
2017-03-12 11:41 GMT+05:00 Sherif Ramadan :
> Yea, but how's that an improvement over using an interface?
>
>
How can I check if an order is ready for checkout with interface? The
difference is in property values, not in presence of methods.
> Example with Rectangle and Square IMO is an example of bad naming in this
case.
I used this example because this is known problem of inheritance. Type
variants solve this problem. Square is a particular case (variant) of
Rectangle.
> PHP already has horizontal inheritance. They're called traits
> 'Order does not match OrderForCheckout. Reason: ...'.
Sorry, this is text for second example) I missed this moment. But I think
the idea is clear.
For manual call of __match() type casting can be used:
$orderForCheckout = (OrderForCheckout)$order;
Also this feature can be used for checking e
Hello. I have an idea which seems rather useful. I would like to know your
opinion,
Let's say we have class Rectangle and need to have class Square which will
be used in some operations. We don't need any rectangle, this must be only
square.
What if we could describe a type which is the same as an
> Thanks, please add start and end dates for voting.
Done. Voting is open till August 6, but I think the result is already clear)
> but after building I've got segfaults
Probably it is because I didn't add PHP_FE_END at the end of function list.
> My *main* issue with this RFC is that I don't con
2016-07-31 1:49 GMT+05:00 Reinis Rozitis :
> From: Michael Vostrikov
>>
>> The problem is that these functions should be called everywhere manually,
>> and there is no error when these functions are not called.
>> And this RFC proposes a solution - call a function autom
>
> What you propose is `Foo::escape()` (static), as a language construct.
>
I have changed the RFC, I wrote about it. Please read the description.
There is no more static calls, there is no hacks with not fully qualified
name.
If any templating engine does that, I'd suggest opening an issue on t
Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.
https://wiki.php.net/rfc/escaping_operator
This RFC introduces new short tag/operator, which will perform echo with an
automatic call of escaping function.
Voting is open till August 6, but it can be
Hello. The RFC 'New operator (tag) for context-dependent escaping' is now
in voting phase.
https://wiki.php.net/rfc/escaping_operator
This RFC introduces new short tag/operator, which will perform echo with an
automatic call of escaping function.
Voting is open till August 6, but it can be prolon
> This new tag will not simply replace because you still need
to output HTML sometimes.
This can be done with e.g. "".
> What you've coined "context" is really just a pseudo function-call - it
does not automatically establish context
Yes. Because the language cannot know the task, it cannot kn
> The aim in my mind would be to make escaping easier to do right, for
people who aren't already using a framework or templating engine with its
own solution.
> The current implementation doesn't seem to share these priorities; it
feels like a building block for framework developers, who probably h
>> if ($context == 'html') {
> this is bad coding style since $context = 0 gives unexpected html
escaping.
I know, it was just an example)
> The RFC speaks of *operator*, where actually start-tags[1] are meant, to
start with.
> Using the word operator is rather confusing in this context.
Techni
> PHP today is a programming language, and applications and libraries can
be and are written in that programming language.
PHP has and tags, all outside these tags is considered as
HTML. It is needed or to remove these tags and use PHP as programming
language only, or to improve usage of these t
I have written many messages already. I think, the purpose of this operator
is clear.
In this discussion I have come up to understanding what I would like to use.
You suggest very hard and complex solutions:
$escape = new SplEscaper; $escape->support('e', function () { ... });
declare('filter=h
> For instance:
> // file1.php
> set_escape_handler('e', 'html_entities_encode');
> // file2.php
> set_escape_handler('e', 'my_own_encode');
> // file3.php
>
>
> If file1.php includes file3.php, it should use first implementation.
> If file2.php does that, so will run the second implementation. I
> I'm conflicted with this one. For you php "More than 90% of output data -
is data from DB and must be HTML-encoded."
> I have no idea how you came with this, even with applications or websites
I'm working on not using a template engine this is far from the truth.
> especially now that more ans mo
> The more you compare it to a function call, the less I understand how it
gains over just defining a function e() and writing
> I might as well just write "function e($string, $mode='html') { }"
> they will already have a method of doing this
Yes, and they have to write a call of it everywhe
> sticking the escaping types after the output makes it hard to spot what's
going on with anything other than a simple variable. e.g. renderView($thing->getViewName(), 'html'), 'js' ?>
In Twig escapers and filters are also written after a variable, and this is
not confusing for many users.
{{ rend
> I suppose you mean that is the unsafe variant.
> How does this rfc makes it not "works good" ? people will still have to
think escaping their data.
It suggests a way when safe variant is as easy as unsafe, without any
additional code. Of course, unsafe variant cannot be removed because of
backwa
> escapeHtml($value); ?>
> I don't see what is hard in using that syntax, plus it's not a global
registry.
> if people aren't using templating and haven't written any of their own
wrappers to sanitize the output
They HAVE own wrappers. The problem is that unsafe variant works good, but
unsafe vari
> Personally I don't know any developer who is using raw php in project
without template engine
Zend, Yii, various CMS like Wordperss, internal business-applications - in
many cases such projects don't have a template engine.
I usually work with Yii and internal applications on custom engines. Thi
> You are creating weird most of time unneded quite complex syntax. Just
use escaping functions or any other escaper or just simply template engine
as most of people does!
I explained the reasons for implementing this operator in previous
discussion and in the "Problem description" section of the
> This can be used for all context-dependent text transformations
On the other hand, this is possible now with . And list of arguments will not be needed if the second argument
will be an array. Ok, nevermind.
A couple of thoughts.
Let's just remove default implementation of PHPEscaper. This is not hard to
define own class, in a global namespace or with 'use'.
Maybe allow to pass not limited set of arguments? E.g. like
This can be used for all context-dependent text transformations - not just
for esca
Rasmus
> Do you get my point that a reference to a closure is state? And if it's
global state, that's extremely bad - the entire PHP community is fighting
like hell to avoid that, with PSR-7 and layers of abstraction on top of,
well, everything, in order to make code testable.
What is the differen
>
> All it is, really, is a registry for functions, and syntactic sugar for
> calling those functions - it's unnecessary, it's more global state you have
> to manage and it's the kind of superficial convenience that will end up
> breeding more complexity.
>
Registry of functions - is exactly how e
>
> Context should be defined where the variable is printed. Otherwise you
> move the variable from HTML text to an attribute or add it somewhere else
> and the context doesn't match anymore.
>
Well, maybe, but HTML is external context and it can be combined with other
contexts depending on task.
>
> Multiple arguments would make the syntax even cleaner:
>
>
I thought about it. Multiple arguments do not allow runtime modification
(and make the parser more complex).
Something like this:
name == 'url') $context[] = 'url';
$context[] = 'html';
?>
>
> 1. Is there any specific reason why we're using a class instead of
> functions to register a callable the same way it's done for exception
> handling or error handling? Hacking non FQN resolutions to inject another
> escaper ...
>
I would not call it 'hacking') This is exaclty the same as if w
> It would be better to return the previous handler, or NULL if one
> wasn't set, in the same way as set_error_handler() does, and for the same
reasons.
Well, maybe you are right.
But I thought, this is not a use case, usually we don't need multiple
handlers for certain context. I.e. we don't need
> if I see it correctly, this is just a framework for defining callbacks to
a escaping operator, without a implementation of "html" and "js"?
> Not sure if this helps.
There is a default escaping for HTML. If there is no registered handler for
'html' context, it calls htmlspecialchars($str, ENT_QUO
Hello.
I have created RFC about context-dependent escaping operator.
https://wiki.php.net/rfc/escaping_operator
Initial discussion was here: http://marc.info/?t=14661919911
At first, I wanted to add a call of special function like
escaper_call($str, $context), which performs html-escaping by
41 matches
Mail list logo
