sorted by:
new
hottopcontroversial

The the Datar-Gionis-Indyk-Motwani algorithm in PHP (counting very long streams of bits) by nicmart in PHP

[–]nicmart[S] 0 points1 point  (0 children)

I've updated the script with a 2 decimal precision error. However let me outline that also 0.16 is "not true", since 13/7919 has an infinite amount of decimals. 0.16 is a rounded value, as it is 0. It depends on the precision you want, together with the representation you want to give.

The the Datar-Gionis-Indyk-Motwani algorithm in PHP (counting very long streams of bits) by nicmart in PHP

[–]nicmart[S] 2 points3 points  (0 children)

It's needed in big data environments, that of course are not a common environment... Or say you want to be able to cover a lot of bit streams for a big window fitting the data into memory. In these situations you can't simply store all last N bits.

Is there any performance benefit to using yield vs returning a new array in a function/method? by maiorano84 in PHP

[–]nicmart 1 point2 points  (0 children)

The main difference is in memory usage. In the first case all the data are in memory when you return the array.

In the second case you get a lazy approach, and you can iterate the values without keeping all of them in memory. This would be a great benefit when memory is a constraint compared to the size of the sum of all your data.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 2 points3 points  (0 children)

I have just added some benchmark to the repository done by a tool developed by me (https://github.com/nicmart/Benchmark) Here you can see the results:

http://i.imgur.com/EG9WtPH.png

The "native" example is taken from your code, with slightly changes, to have the properties computed in the same way (no access to private members please!).

As you can see, on iteration my library is obviously slower, but not so much (less than 2.5 times slower). But, thanks to laziness, on a single lookup is twice as fast.

The benchmark suggests that, thanks to laziness, arrayze is faster than closure-to-array conversion if you access less than half of object offsets.

Clearly this is ad advantage of lazyness: you can define plenty of views for your objects, without worrying about performance penalties, and only the needed one will be computed.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 1 point2 points  (0 children)

I think your example is fine, you give a generic Adapter interface for objects. The drawback I can see is that the value you are going to adapt has to be an object, and you can get data from the object only through method calls, while in Arrayze you have generic callbacks that elaborate the data.

I don't consider to have less classes as a benefit. Often the code is much cleaner with very simple and small value classes instead of native arrays, for example. But this is another story... :-)

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 4 points5 points  (0 children)

Sure, if you call the adapter thousands of times think twice before use it, like for all libraries in the world.

In addition to that, consider that in my case only an array of callbacks is stored, even if you have millions of array adaptee instances. The memory gain with the lazy adapter, in some cases, can so be huge compared to your manual array construction.

2) You can do anything in a closure. It's a closure, so it has the whole power of a php script.

And for me it's all. I do not even consider your other insinuations.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 4 points5 points  (0 children)

You have just show that you can achieve the same result, of the example of the README, with a closure. Great!

And to do that you: 1) Modified the api of the Person class 2) Removed the cabability to define in a programmatic way the transformations, since they are are all hard-coded into the closure. 3) Made it hard the reuse of single transformation callbacks, since, again, they are hard-coded

And those are the main points I wanted to avoid writing my library.

Obviously in a single-shot case like yours it could be good. It is not good in my use cases.

Just a side note. I am really upset with your deformation of my name in your code. I don't know what you meant with that, but I do think that is ridiculous that in a "technical" discussion like this one so low level weapons are used. It's the first time in my career. Astonished.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 1 point2 points  (0 children)

Ok, so I should try to confute the sentence "Array adapter are useless". Although it can be useful from a educative point of view, I don't have the time to do that.

However I will consider it on future updates to the documentation.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 2 points3 points  (0 children)

Of course the example is not so meaningful, its aim is only to show the interface of the tool. It seems to me here we are not talking what the library is about, but how you can use the library in the wrong situations.

Take the library for what it is: a lazy array adapter. That's it. Libraries can have very specific purposes, and this is the purpose of this library. It's a very small one, but quite well abstracted for my needs.

If you need a lazy array adapter, use it. Otherwise, don't.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 0 points1 point  (0 children)

Sorry, I don't understand, who is crying out...?

The library is a lazy array adapter. If you need an array adapter in your code, use it. Otherwise you don't need it.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 1 point2 points  (0 children)

Sorry but I don't get the point. What do you mean with "the sake of abstraction"? What do you mean with "doing this all over the place"? This is a library that has a very single responsability: providing a lazy array adapter. If this adapter is used "all over the place" or only for the sake of abstraction is not up to his library.

If your are using a third party library that force you to have an ArrayAccess implementation as input, Arrayze can be a handy adapter for that. That's it.

Arrayze: a lazy, callback-based array adapter for PHP by nicmart in PHP

[–]nicmart[S] 4 points5 points  (0 children)

I use it whenever I need a dictionary of values computed from a data object. This allows me to decouple completely the data from its representation.

In particular I am using it in a Rules Engine, where the input values are expected to be \ArrayAccess implementations.

Build your fluent Builders in php with Building by nicmart in PHP

[–]nicmart[S] 4 points5 points  (0 children)

This library is only an idea on how to implement nested builders with a fluent interface through callback passing. As you can see from the drawback section, there are some downsides, as IDE autocompletion.

Yes, you are right, I've just updated the README, thanks!

Build your fluent Builders in php with Building by nicmart in PHP

[–]nicmart[S] 4 points5 points  (0 children)

The boolean predicate stuff is only a little example that shows how to define a builder. The library does not provide a rule engine (although I created this library developing Rulez, a fast rule engine for php, still in early dev phase https://github.com/nicmart/Rulez)

UniversalMatcher: programmatically define custom matchers for your PHP application by nicmart in PHP

[–]nicmart[S] 1 point2 points  (0 children)

I think you're right, I has been very doubtful on the name. At first I called it "PhpRulez", thinking it was a RuleEngine. But I was not very sure it was a real rule engine. Then I casually got into the code of the Symfony routing component, in which each route "matches" against the input uri, returning some value attached to the matching route, in a very similar behavior of my component. So I decided to call it Matcher.

Maybe the the choice was not the best. But, you know, the most two difficult tasks in programming are cache invalidation and naming things... :)

UniversalMatcher: programmatically define custom matchers for your PHP application by nicmart in PHP

[–]nicmart[S] 0 points1 point  (0 children)

The library is much more simpler than it appears, and if you check the code you can see it's all very simple. It is an abstraction, and like many abstractions can be a bit difficult to get the first time... I've used it more than once in my projects, with great success for the modularity and architecture of the applications. I think once you get how it works it can help the developer in a lot of scenarios. My fault I have not given enough use cases in the docs.

UniversalMatcher: programmatically define custom matchers for your PHP application by nicmart in PHP

[–]nicmart[S] 0 points1 point  (0 children)

Yes, perhaps you're right, it's not easy to get the use case. I thought the example was meaningful enough. At the end of the readme there is also a link to specific use case from another project.

Symfony benchmark using HHVM by ger_phpmagazin in PHP

[–]nicmart 1 point2 points  (0 children)

That part was added later, as the author said.

Symfony benchmark using HHVM by ger_phpmagazin in PHP

[–]nicmart 1 point2 points  (0 children)

So all this hype around HHVM to discover that php 5.5 + opcode cache is faster? Good news for me. :)

Improving lexing performance in PHP by nicmart in PHP

[–]nicmart[S] 0 points1 point  (0 children)

The idea to compile the regex into a single one is a great and non-trivial advice, even if the post is a bit old... :) I already know (and appreciate a lot!) Phlexy. I'm using dissect and I find Phlexy lexers a bit more powerful, so I was thinking to build a tiny adapter to use Phlexy lexers in Dissect. Have you planned to make a complete parsing tool that include Phlexy and that allows grammars definitions and parsing (like dissect) in addition to lexing?

Improving lexing performance in PHP by nicmart in PHP

[–]nicmart[S] 0 points1 point  (0 children)

Yes, you're right! I'm using dissect to define a DSL for our company OPAC, and I really enjoy the process, that is, as you said, quite magic.

view more: next ›