Skip to content
This repository was archived by the owner on Nov 23, 2025. It is now read-only.
/ finder Public archive

argument $masks in find methods made required#5

Closed
vlastavesely wants to merge 1 commit into
nette:masterfrom
vlastavesely:master
Closed

argument $masks in find methods made required#5
vlastavesely wants to merge 1 commit into
nette:masterfrom
vlastavesely:master

Conversation

@vlastavesely

Copy link
Copy Markdown
  • bug fix? yes
  • BC break? no

@dg

dg commented Feb 19, 2017

Copy link
Copy Markdown
Member

I like more explicit findFiles('*')

@vlastavesely

Copy link
Copy Markdown
Author

OK, but, in my opinion, it is problem that if you call it with empty $masks, you get notice Undefined offset: 0 in instead of something more meaningful.

@dg

dg commented Feb 20, 2017

Copy link
Copy Markdown
Member

And can you fix it?

@vlastavesely

Copy link
Copy Markdown
Author

yes

@vlastavesely

Copy link
Copy Markdown
Author

Argument $masks is now required. Do you like it more?

@vlastavesely vlastavesely changed the title added fallback for empty $masks in find methods argument $masks in find methods made required Feb 20, 2017
@dg

dg commented Feb 20, 2017

Copy link
Copy Markdown
Member

What about to change declaration to findFiles($mask, ...$masks), ie. native enforce first parameter?

@dg

dg commented Feb 20, 2017

Copy link
Copy Markdown
Member

And perhaps use only one way: the array or more parameters. The second way should be deprecated.

@vlastavesely

Copy link
Copy Markdown
Author

What about to change declaration to findFiles($mask, ...$masks), ie. native enforce first parameter?

I think it would be unnecessarily overcombined and little bit confusing.

@vlastavesely

Copy link
Copy Markdown
Author

What about to unify API of Finder and RobotLoader in some way? RobotLoader accepts array or comma separated string while Finder accepts array or argument list. I like the array|string version or only array eventually.

@JanTvrdik

Copy link
Copy Markdown
Contributor

It may be just me, but I would prefer that calling findFiles() without arguments was allowed and always resulted in finding nothing.

@vlastavesely

Copy link
Copy Markdown
Author

I can imagine I would be a little bit confused if function named find() returned nothing and did not throw any warning or error.

@Majkl578

Majkl578 commented Mar 7, 2017

Copy link
Copy Markdown
Contributor

and always resulted in finding nothing

And someone might expect the opposite, find all files (i.e. no mask -> no filter -> find everything).

@f3l1x

f3l1x commented Jun 21, 2017

Copy link
Copy Markdown
Member

I agree with @Majkl578 and also with @JanTvrdik.

findFiles can be understood as find-all as well as find-nothing. What about clarify to findFiles()->all(),allFiles, findFiles(Finder::ALL). Also we could require at least one argument to findFiles.

Just an idea, let's discuss it.

@vlastavesely

Copy link
Copy Markdown
Author

According to me, function that does not find anything by default is useless.

Take Linux command find for example. Does not matter whether you run it by find or find .. It always finds all files in the directory unless you limit it by some pattern.

Another thing: imagine you have a directory and you want to check whether it is empty. You call Finder::findFiles(), it finds nothing and you remove the directory with confidence. But it contained important files you did not back up... You lost your files only because you forget to specify pattern when finding files...

@enumag

enumag commented Jun 22, 2017

Copy link
Copy Markdown

I also think findFiles without any mask should return all files. It makes more sense then returning nothing and is consistent with similar tools.

@dg dg closed this in 4958820 Jun 22, 2017
dg added a commit that referenced this pull request Jun 22, 2017
@f3l1x

f3l1x commented Jun 22, 2017

Copy link
Copy Markdown
Member

Thanks @dg

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants