Closed jpbro closed 7 years ago
The same would go for property names for those objects too...For example, currently the CPcreMatch object has a MatchedText property, but the VBScript Match object has a Value property. Should we consolidate these?
There are so many options and functions in pcre2 that do not have an equivalent in VBScript, so I would prefer to have the parameter names based on those of pcre2.h.
For the class names, I would like to see the prefix CPcre2 in line with the library origin.
Okay. Let's revisit requirements. I don't think VB6 beginners will rush to use this COM-library. It's generally for us, who really know where to use it and why. However, we also will equip it with a small manual (description) with very basic properties and methods. Thereat all main properties will be described well. So, maybe, I think there is really no need to copy VBscript. And especially, complicate code with some 'reserved' words. +1 to @nouba.
Hi guys, sorry for the delayed response - power was out all day here yesterday while some infrastructure was being upgraded.
So I'm happy to use our own names that align better with Pcre2 vs. Vbscript regex as well - I opened the ticket because of a conversation with @dragokas on another site regarding being more closely aligned with Vbscript, but since everyone now seems to be on-board with Pcre2 names, let's do that :) Thanks for the feedback!
Before finalizing the object model and compiling as a DLL with Binary Compatibility set a decision needs to be made regarding the class names.
Right now things follow a CPcre* naming convention, but would it be preferable to match the object names of the VBScript library (e.g. CPcre = Regexp, CPcreMatches = Matches, CPcreMatch = Match)? This will make it easier to use the library as a drop-in replacement for VBScript.
I'd appreciate any thoughts on this from the community before making a decision one way or another.