In the world of systems, you ahve two extremes, high abstraction of duty, and none. Then there's the inbetween. I looked at the problem from the php perspective. php is a templating language that you can code in. So you wind up with 3500 core functions and the ability to put anything anywhere.
So back to your example. If I had no framework, I could create a module and various objects that work as validators on other objects. That would be a new framework, true. But it falls into the trap of being a validation language I can write code in. For this very reason, I'm not fond of many template languages and similar which allow raw code to be executed. Why would I ever wish to use DBI from this to validate my data as being of certain standards?
So for instance, sigil's are gone in my language for data types, since a scalar in perl terms is just a 1 element array in my language, where you just don't use the index. You have trinary compares for < and > for easy betweens. You have variables taht refer to the outter world as :someVar.
To put it in the frame of mind of an architecture. What I would do in the past, is use something like HTML::Template and CGI. I would take in all my inputs, create an object tree of things like User, Group, Message, Topic, Node, populate them with my data, and call various functions to validate each object in the object tree. Each object would be validated in the native language and returned.
But I run into a similar problem of replacing HTML::Template w/ here-docs. Yes, I can perform invalid syntax in either, and accomplish the same in either, but the here-doc method can be very powerful. Almost TOO powerful. If I'm smart and good and all, I can accomplish a pristine system w/ no issues of what is doing what. If I'm bad and/or not as smart, I can start doing DBI calls in places I'll be rendering templates. That scares me. It's the same issue of actually using php as your template language, or JSP as a coding language.
Heh, imagine if you wrote DB queries in perl instead of SQL.
The advantage I propose, is the same as HTML::Template, Class::DBI and Catalyst. I can have clear seperations of duty, that are done very well, and won't comingle. The template language only makes stuff well formated, where Class::DBI takes objects and stores/retrieves them for me, where as catalyst deals w/ URIs, what is called and the clear seperation of one thing from the next. With verify, I can start out w/ nothing, and fill in the validation w/o worrying about stepping on things like Class::DBI or HTML::Template.
BTW, mind you, I never said the underlying language /was/ perl, but even if it was, it is a very simple subset. | [reply] |
The thing is that your proposed language is almost raw code. ;-)
I think that splitting everything up in different layers of abstraction is the way to go. I wasn't criticizing the concept.
This is completely subjective, but I tend to dislike mini-languages. E.g. although I use Template Toolkit, I'd be much happier if it used a slightly modified Perl (which the only major difference would be the removal of curly braces) instead of its own language. I even considered using Template::PSP but it really doesn't have all the features I need.
Going back to the specific example you gave, Class::DBI and Catalyst are substantially different from hand-written SQL and plain CGI coding. While your proposed language is not.
If I were to implement a verification language, the "code" would probably be some sort of subset of YAML (not because it would ease parsing, but because I really like YAML) and look something like this:
# type checking
parameters:
# + concatenates rules, pad does smart padding
flight_number: char(2) + pad(integer(0 .. 9999))
flight_type: char(1)
# variable passed as a parameter to the template
total_seats: integer(0 .. :total_seats)
occupied_seats: integer(0 .. :total_seats)
# length checks the list, "of string" could be implicit
passenger_list: list(0 .. :total_seats) of string
# further validation and processing
processing:
# & references a previously declared field
# :flights_table could be a list or a hash
# this might be more appropriate to be on
# the previous "parameters" instead of here
- exists &flight_number in :flights_table
# maps the flight type code into a descriptive string
# using the flight_types hash
- map &flight_type into :flight_types
# some simple and obvious checks
- check $occupied_seats < &total_seats
- check &passenger_list = &occupied_seats
# in-template variable declaration
declare:
flight_types:
A: Commercial
B: Non-Commercial
C: Cargo
In fact, I actually really liked this idea. I might consider implementing it, if I have the time. ;-)
acid06
perl -e "print pack('h*', 16369646), scalar reverse $="
| [reply]
[d/l] |
The thing is that your proposed language is almost raw code. ;-)
Wait. What? I think you are misunderstanding the difference between the language and the interpreter. The interpreter interprets a language. I'm sure CDBI uses a perl interpreter for the custom sql language it uses, though it may be c, or c++. Doubt it's ruby. The point of it is to BE code since you can't do branching w/o some level of code. I.e. If your country is england or canada, your postal code can be alphanumeric. If it's a small island (like mine), you don't have one.
By using Yaml, yaml is your language, and I'm assuming perl is your interpreter. For this, Verify is my language, and my interpreter is written in the native language. Basic, perl, java, c, fortran, whichever.
This is completely subjective, but I tend to dislike mini-languages. E.g. although I use Template Toolkit, I'd be much happier if it used a slightly modified Perl (which the only major difference would be the removal of curly braces) instead of its own language. I even considered using Template::PSP but it really doesn't have all the features I need.
Then this RFC isn't for you. As I've pointed out, if you can seperate everything in your regular langauge, and everything is done well and such, great. It shows you have diligence and the people around you do too. It's the same argument I have for php. Yes, php is a language, and if you are very diligent w/ it, you can do great things. Problem is a lot of people out there aren't, and try to short cut themselves into oblivion.
Take a look at the internals of drupal. Or osCommerce. Not fun.
Going back to the specific example you gave, Class::DBI and Catalyst are substantially different from hand-written SQL and plain CGI coding. While your proposed language is not.
I beg to differ. For one, what constitutes data as being valid, vs logic that manipulates the data (controller stuff), the actual model, the visual-ness, the confiuration alnguage for my application and such, can all be seperate. I would not wish to use my model tools to calculate pi, my visual stuff to start doing DBI calls. Nor would I want my configuratoin language to be used for validating of data. It's been done before, and it can get quite messy trying to describe dependencies.
If I were to implement a verification language, the "code" would probably be some sort of subset of YAML (not because it would ease parsing, but because I really like YAML)
And there in lies the rub. Some people will believe in doing it all in code, some people believe the XML format of jakarta validation is awesome, and people like you believe in YAML. This is really not a problem.
To give you my personal opinion, the XML format, describing dependency is a pain when you wish to start saying, certain combinatios are good. Heck, try doing password valdation (password=passwordverify). One winds up writing a lot of validation stuff in native code, and parameter passing in the XML format. It gets /very/ verbose. It can also be error prone.
Native code, like using perl, or c, or basic, or java, gives me too much power. It becomes like php, as I've said before, 3500 core functions. What do I need any of that for? It's like writing queries IN perl. SQL is so much better suited due to design.
As for yaml, yaml is a nice. Really. But you broke a cardinal rule, simplicity. I do not want type checking. It's why things like excel work so well for it's formula language. It takes a little effort to do things wrong. In c, it's easy. Try miscasting something. I also didn't care for the abundacy of sigils. I did not wish to use them, but I ran into a problem with collisions of variable names, so :password is an external variable, where password isn't. It becomes like some SQL languages.
In fact, I actually really liked this idea. I might consider implementing it, if I have the time. ;-)
Please do. What we need are good systems being written. Bad systems weed themselves out. We all evolve. We write less in c because other languages are "easier" to write in, and do more for us. We have ACID compliant databases, 'cause dealing w/ semaphores can be such a pain in the ass on the coding level. We have LWP and Net::FTP because it's getting old, rewriting ftp clients all over the place. The purpose of this is so that I can write a good RFC, that is complete, and helps me write a complete system that is a puzzle piece in a set of pieces for a complete architecture.
| [reply] |
The thing is, your example on location and associated ZIP code syntax, is one example of why a database lookup could be a good idea in a data verification language. Do you really wish to pile rule upon rule, in "code", for a single association, location<->ZIP? It seems to me like a table holding those associations would be a better idea.
| [reply] |
I don't have a good answer for this. So bear with me. Maybe the salesperson example is bad, because of the context. I.e. a valid node id is numeric, where is a usable one is somewhere below this node number at creation time, something higher in the future.
I probably shouldn't have specific data checking that is DB related built in.
Btw, in the US, zipcodes are all 5 digit,then and extra 4. 00000-0000 is valid in syntax,but not in the context of being available, or usable. Just as the name xxxxxxyyyyy isvalid in most countries that use the alphabet, but you can't pronounce it.
Thoughts?
| [reply] |