What about renaming it toMacAddress?

What about renaming it toMacAddress?

For meMac was cleaner, because theIp constraint is not calledIpAddress (consistency) & there are no different meanings of the wordmac, so no conflicts

there are no different meanings of the wordmac

I see what you did there. 🍏

What about renaming it toMacAddress?

I actually find this name more relevant than simply puttingMac

I see what you did there. 🍏

Hahah, seems I'm so "anti Apple", that I forgot one of the most known names in world... :D

I don't think there will be any constraint used in real scenario to check mac devices (mac device names?) - but if, the constraint should be a prefixed with the name of the company, e.g.AppleMac. But I can change it toMacAddress, if preferred, just let me know :-)

As I said in#51777 (comment) I am not convinced that this is a common enough use case to be part of the Symfony core.

I am not convinced that this is a common enough use case to be part of the Symfony core.

Yeah, maybe we should encourage releasing niche-y validators as standalone packages more.

Then again, we have other network-related constraints, like the already mentioned IP and CIDR. What makes this one different?

To me aMacAddress is general enough to be part of the core.

I vote for naming itMacAddress.

Then again, we have other network-related constraints, like the already mentioned IP and CIDR. What makes this one different?

I can work with a client's IP address. But for MAC addresses I do only get the one from the latest hop.

@Ninos can you please elaborate on your use-case? Thanks

To me aMacAddress is general enough to be part of the core.

I vote for naming itMacAddress.

I voteMacAddress too

Renamed toMacAddress, hope it's fine now :-)

can you please elaborate on your use-case?

Application e.g. for storing device specific mac addresses

PR rebased ✅

I still don’t see this as a common enough use case, but I won’t insist if others agree with adding this constraint.

Thank you@Ninos.