Recent Forum Posts
From categories:
page 1 of 212next »

The new code is up (finally). It's nothing near completetion but you can take a look at the parts of the Reflector class that work specifically with custom attributes. Basically, there are ways to combine custom arguments with proxies or when performing call interception to give the proxy/intercepting code a way to know what to check for. However, from what I understand both of these methods are computationally expensive. Unfortunately, I've yet to find anyone who's done comparisons or respectable analysis of the cost, so it may still be feasible? That's something I'd like to look into or have someone else look at (are you interested?) so at least whatever we go with will be the best reasonable solution.

If you're interested in officially joining the project, I've posted openings on the sourceforge.net site. If you can't find them just shoot me an e-mail with your account name to moc.liamg|anihcamxexela#moc.liamg|anihcamxexela. I can add you to the project that way. And if you decide to take on researching something like that I can add some tasks to the plan to track against.

Hey Alex, looking forward to seeing the new drop of your code.
So do you think a custom attribute could be used for argument checking? I've been reading up a little and must say I'm still a little stumped on what the implementation would look like…
Good luck getting your release out the door!

cheers,

Roland

Thanks for participating :)

I agree. And actually, I was thinking about globalized error messages today. I agree that it's something we should try to plan for. I've had quite a bit of experience with custom attributes :) Actually, I need to put the latest chunk of code up for Nvigorate. I've finished most of the Reflector stuff I just lack the rest of the NUnit tests.

I'm currently working on 2 things. 1) Finishing up the DataInterface class and testing it to make sure it's at least mostly operational 2) Stubbing out interfaces and the basic implementations for the Relational (used to be Binding) namespace.

Hopefully I can get organized better soon so that anyone wanting to contribute code will actually know what the design is like. I'll post a line on the news page once I get everything uploaded this evening.

Yep, argument checking is a big point of argument (whaha, do I get points for bad puns?). From a best practices point of view I'd agree completely, just for the sake of full and utter completeness it would be a good thing.
But from a logical point of view, its just superfluous, in most cases its very logical if an argument is nullable or not. You know, consider a method such as UpdateUserAccount(Account accountObj). I think its rather obvious that you need to pass in a valid object here.

But then again, you are building a FOUNDATIONAL library here, so in NVigorate's case I'm actually in favor of throwing exceptions that cleanly explain why certain arguments may not be null. And by throwing custom exceptions the user of the library is also able to catch these exceptions and act accordingly.
A global exception mechanism for the entire library might be in place here, I'd recommend working with global error indentifiers that refer to string representations in a resource file. That gives you even the opportunity to raise errors in different lannguages :)

As far as implementation goes, maybe its a good idea to create a method Attribute class for this? I have zero knowledge of the whole Attribute side of things, but to me this sounds like a logical route to take in this case.
Does anyone around here have sound experience in creating custom attributes? I think I'll start reading up on that aspect of .NET, should be interesting…

I've been struggling lately with whether or not to check all the arguments for null or empty string. While many say that it's best practice, I've yet to actually see this done. While it might definitely make the entire framework far more debugging friendly, I wonder if it's worth the extra effort and expense.

Scott Wagner, a .Net Solutions Architect has come up with (what I believe) is a simple enough solution. An argument checker class provides a way to tie delegates to the type of argument to check. Checking the argument is accomplished by calling a static method and providing the argument name and error message in the event that the argument does not pass the check.

For the time though, I will not be trying to incorporate any approach until I've gotten further along in the development of the basic classes. This is partly because at this point, I'm trying to get a good deal of code up to standard and make sure it's passing general unit tests.

I would like to hear some feedback on this matter so please chime in.

Oh, and in case you were wondering, these are the codeproject articles I was refering to:

http://www.codeproject.com/dotnet/Creating_Dynamic_Types.asp

http://www.codeproject.com/useritems/Creating_Dynamic_Types2.asp

Also for anyone else who's interested in this subject matter, its a good read for an introduction into the Reflection.Emit namespace

Hey there again Alex,

thats funny, I was just reading an article over on codeproject about the Reflection.Emit namespace and was immediately thinking about NVigorate haha. I wasn't aware yet of this .NET functionality, but it is pretty awesome. It would indeed be a very powerful feature for NVigorate to encapsulate this functionality, because I'm sure there's plenty of programmers who aren't that enthusiastic about passing around .NET opcodes :)
Another interesting implementation would be for the System.CodeDom namespace, so instead of a fully working type a programmer can just generate the source code for later compilation.

You're definitely on the right track here, keep us posted and thanks a lot so far!

cheers,

Roland

Hi Roland,

That's a very good example of a simple factory and it's a very large reason why I wrote Reflector to begin with. But I'm talking about something a little crazier that I've done in the past where I actually define a class type on the fly using the Reflection.Emit namespace. You're actually creating a CLR object at runtime in memory and then you can take the resulting assembly and save it to disk. The trick part is that the system/application utilizing these has to have some kind of permanent caching system so that it knows that an object with X parameters of the specific types = this assembly that was created on the fly and saved last time. That's to prevent needless re-creation of an assembly which just has the same type. This is also because if you try and create the same CLR object in memory w/ the same name your app *will* crash :)

The code you've demonstrated is actually very close to one way in which IBinder and IMapper classes work together. IBinder essentially copies data from one source to another, but it needs mapping information which is provided by IMapper. These two Interfaces are abstract enough that the implementations will do things like binding data table information to class instances, like you've demonstrated.

I'm very glad that you can see the usefullness of the class, that lets me know that I'm on the right track!

Thanks,

Alex

Hey Alex,
I've been nosing around the Reflection class you posted, interesting stuff so far. I have a question about the planned features, especially about the 'on the fly' generation of types from various inputs. How generic are you able to make this? I mean, I can imagine creating objects froma DataTable like this (i'm using some NVigorate functions in the code below):

public static object[] CreateObjectsFromDataTable(DataTable aTable, Type aType)
{
    object[] ObjList = new object[aTable.Rows.Count];
    for(int i=0;i<aTable.Rows.Count;i++)
    {
        ObjList[i] = CreateObjectFromDataRow(aTable.Rows[i], aType);
    }
    return ObjList;
}

public static object CreateObjectFromDataRow(DataRow aRow, Type aType)
{
    ConstructorInfo aConstrInf = aType.GetConstructor(new Type[0]);
    if (aConstrInf.GetParameters().Length > 0)
    {
        Throw(String.Format("{0} does not have a parameterless contructor", aType.FullName));
    }
    object aObj = aConstrInf.Invoke(new object[0]);
    foreach (DataColumn aColumn in aRow.Table.Columns)
    {
        WriteProperty(aObj, aColumn.ColumnName, aRow[aColumn.ColumnName], new object[0]);
    }
    return aObj;
}

In this example I'm assuming that the column names are the same as the property names in the targeted type. Should they not be the same then I guess the DataTable would need additional 'massaging' before its passed to the function.
Is this roughly the type of strategy you have in mind? So how would this work for filling an object from XML? Would you simply pass in a node collection that uses the element's name as the property binding?

Anyways, I think the Reflection class shows great potential for all sorts of object factory type of work, I'll be watching NVigorate's progress closely. Thank you very much for your efforts so far.

cheers,

Roland

On the fly type generation by mechheadmechhead, 10 Mar 2007 21:53
Re: Goals
alexexmachinaalexexmachina 08 Mar 2007 06:53
in discussion Nvigorate Design / Roadmap » Goals

Great point Bob,

I'm sorry I hadn't addressed that earlier. The current code is 2.0 only. Initially my framework was based on 1.1 but I moved a lot of things over to take advantage of generics and so the code will target 2.0.

As for the differences between .Net and Mono, we will probably fork the code at some point for .Net and Mono support simply because LINQ support is a must (in my opinion). In fact, I'm hoping to take future LINQ integration into design considerations. As of Feb 15th, Miguel de Icaza was already talking about the advances they have on the C# 3.0 compiler, so I think it's possible they'll be rolling out LINQ support soon after M$ gets their 3.0 distribution to production.

So a lot of that rambling was to say that I agree with you 100%, targeting 1.1 would be a poor way to encourage adoption. Thanks again for your participation, I'm going to go update some of the wiki :)

Re: Goals by alexexmachinaalexexmachina, 08 Mar 2007 06:53
Re: Goals
Bob GrommesBob Grommes 08 Mar 2007 06:20
in discussion Nvigorate Design / Roadmap » Goals

Alex,

Do you plan to target CLR 2.0, or at least the subset of that which the stable Mono release currently supports? Or are you initially going after CLR 1.1? There are an awful lot of 1.x projects that probably will not move to 2.x+ for a couple of years. If I were in your shoes I would probably target 2.0, however, since by the time Nvigorate is to v1.0 that will probably be the baseline.

—Bob

Re: Goals by Bob GrommesBob Grommes, 08 Mar 2007 06:20
Re: Goals
alexexmachinaalexexmachina 07 Mar 2007 19:04
in discussion Nvigorate Design / Roadmap » Goals

Hey Roland,

As far as right level of experience, I don't think that can be measured in years, so don't let that get in the way of participation. The whole purpose of this project is to benefit everyone who participates or just wants to use the code itself and the more people who put in their 2 cents, the better chance we have of creating something truly useful and unique.

Your question is not stupid, it's an excellent question. It will be a matter of days before the code is "up". What that means for now is that the code will get posted on a wiki page. Right now I'm waiting for the folks at SourceForge.net to review my project application to see if they'll grant us SVN space there. I would share my personal SVN instance with everyone except I can only grant full access (not just read) so it would mean anyone who wanted to could do anything to the source which makes me just a tad nervous since you never know what could happen.

Right now I'm doing 3 things. Finishing up unit tests for the first portion of the Reflector class, planning the next portion of the Reflector class to bring into the source and writing an XSLT script that takes the Xml document comments from the source code and turns them into wikidot's own markup syntax. This way I can put the developer documentation from the source directly into the wiki after applying the XSLT, this will save me HOURS of typing and editing.

I hope no one is afraid or shy to ask questions, this is a new project with only a little bit of info to go from so I understand that there are going to be a lot of questions. Questions are good, ask away!

Thanks for showing interest,

Alex

Re: Goals by alexexmachinaalexexmachina, 07 Mar 2007 19:04
Re: Goals
mechheadmechhead 07 Mar 2007 12:23
in discussion Nvigorate Design / Roadmap » Goals

Hi Alex,

I also came across your announcement at the daily grind. I think your general goal for NVigorate sounds very interesting, I'm not sure if I have the right level of experience to participate (5 years of Delphi, about 2 years of C#/.NET) but I'm definitely willing to give it a try. Being part of a project like this would be an excellent learning experience as well I think.

So now for the stupid question: When will you be posting your first code? Is this a matter of days, or weeks? Whats the biggest thing holding you from releasing? Is it actually finishing the code itself, or perhaps documenting it?

Sorry to sound like a nagging child here, hehe, I'm just very curious.

All in all, I really hope this project will take off, so I wish you all the best!

-Roland

Re: Goals by mechheadmechhead, 07 Mar 2007 12:23
Re: Goals
Bob GrommesBob Grommes 06 Mar 2007 02:09
in discussion Nvigorate Design / Roadmap » Goals

Thanks for the response, Alex.

I agree that most of the frameworks I've looked at seem over-engineered and bloated. Combining the BSD licensing with relatively self-contained function points plus avoiding idological axe-grinding sounds like a great combination. The ability to use part or all of the framework is very attractive to me.

Looking forward to that "first little bit of code"!

Re: Goals by Bob GrommesBob Grommes, 06 Mar 2007 02:09
Re: Goals
alexexmachinaalexexmachina 05 Mar 2007 23:49
in discussion Nvigorate Design / Roadmap » Goals

Thanks for asking these questions because they're ones I hope I addressed in passing but also, I've been working on this in some form or fashion for so long, I take for granted that the abstract language I use to describe some of Nvigorate's qualities don't really help new people get any feel for what Nvigorate is/will become.

I don't want to tear down the efforts others are putting into their framework, but let me just say that I've had several of the more popular projects recommended to me by people who heard I was working on a framework that did X. There is something to be said for not re-inventing the wheel for no reason. Unfortunately, I have yet to find a framework that I personally feel is up to snuff, but all of them have so much code in place already that it didn't feel appropriate for me to stick my big nose in and start telling them what needed to change. So instead of naming open source projects, I'll focus on aspects of those frameworks that I felt make them inferior.

  1. Many frameworks I've seen are extremely limited in what you can do with them. They are designed to force you into developing according to the architecture of the framework itself. While that may be fine to do internally at a large company who writes their own software, that's not a practical approach to take when making a general purpose framework for others to use.
  2. Most of the frameworks appear to have been designed for a very limited scope. I've often found that some of them will only work under very controlled circumstances. For example: Class Thingy in their framework might say it's a general purpose database interface class, but as it turns out, it's really only meant to be used by one of their other classes, so your chances of trying to adapt the database access portion for customized purposes are slim to none.
  3. One or two I've seen lean very heavily on some technology or fad. The library revolves around some mindset so much so that it almost feels like the project was done as a class exercise to reinforce a newly taught principle. While that may work great for canned, small scale applications, it generally won't meet the needs of your average enterprise-sized application or system.

Nvigorate takes on more of a foundational class library approach than does any other project I've had time to really analyze to date. The framework is more general purpose in that it provides common interfaces, utilities, abstract factories and functional singletons. While it will do things like provide a very easy-to-use, yet versatile database interface class, it will also offer some more advanced functionality like data binding and ORM. But the differentiating factor in places where Nvigorate and framework X fill similar roles, the focus of Nvigorate is to help the developer build a best-class data binding and/or ORM solution rather than providing them with a limited and canned solution which forces them to design and develop against someone else's design.

I intend to address this more as time allows. Right now, I'm trying to get the first little bit of code done so I can post it and let people have a look. So much to do, so little time :)

Re: Goals by alexexmachinaalexexmachina, 05 Mar 2007 23:49
Goals
Bob GrommesBob Grommes 05 Mar 2007 21:50
in discussion Nvigorate Design / Roadmap » Goals

I found this project from a blog posting (the Daily Grind, IRRC) that said words to the effect that this "looks more like an ambitious project announcement than an actual product". Fair enough. But if this project is to attract contributors and move forward quickly enough to not join that Big Project Graveyard in the Cloud, some thought should be given to that yuccky topic of "marketing" IMO.

In the FAQ, you state "I was disappointed by what many other projects had to offer. The design approach I intend to follow should yield a cleaner architecture that offers users a lot more flexibility." It would be a great statement of purpose / goal for all of us if you could hold forth on that in a little more detail. What I hope you mean by this is that Nvirgorate will be simpler, more approachable, and easier to grok while still being powerful and useful. But how, exactly?

I note also your desire to be cross-platform between the Microsoft and Mono stacks. That is a great thing, although to be honest I haven't researched the alternatives enough to know if this is a point of differentiation or not.

Come to think of it … who do you see as your competitors and how will you best them?

I solicit comment on these topics because IMO these things need to be fleshed out and communicated in order to motivate people to join your effort in a significant way. It's fun to be in on the very ground floor of a new project … but there are a lot of them to choose from. Why is this the one for me (or anyone) to focus on?

Thanks!

Goals by Bob GrommesBob Grommes, 05 Mar 2007 21:50

I have heard that if you have about as much code in unit tests as in the code being tested, you've got it about right. Personally I'm not so sure about that as a blanket statement. In the real world I've used formal unit testing almost exclusively in library / framework types of routines, and I can see testing code rivaling the volume of tested code in that scenario. I don't find unit testing *nearly* so useful in UI code and the like, though.

I'd say that if your tests work correctly, have good coverage and run reliably such that you're not spending a lot of time debugging your tests, then you've probably hit some kind of sweet spot. IMO, test code is allowed to be kind of ugly so long as it's not obtuse or difficult to work with.

I think you'll find that BSD-type bracing is more prevalent in the C# world, although K&R is by no means a rarity. I'm guessing about one-third K&R, two-thirds BSD. At least based on my own experience.

I just hate devoting an entire line to a bracket. I don't like brackets *that* much. On the other hand I leave a line of whitespace between code blocks anyway, so it's truly a matter of personal preference.

Re: Bracing Style by Bob GrommesBob Grommes, 05 Mar 2007 20:43

Hey Bob,
Glad to see the forum is working now! Thanks for the comment, what it comes down to is, I have preferences about coding styles, however, if the majority of contributors and users would rather use a different code style, like with the braces, we would switch to using that. I'm used to seeing the BSD style bracing so to me, that's readable, but if it happens that that's actually a very uncommon and/or disliked style, then it's obviously not readable to everyone else and therefore a detriment to the project and the readability.

I can always adapt to things like this, so if others are reading this, please throw in your 2 cents! If you like The One True Bracing Style, sound off and Bob will thank you when we change the standards :)

If you're curious about different standards for bracing/indention you might find the wikipedia article interesting: Indent Style.

Re: Bracing Style by alexexmachinaalexexmachina, 05 Mar 2007 19:08

I'm sorry to see that you've chosen BSD / Allman style bracing. I am one of those people who prefer K&R / 1TBS — I hate vertical scrolling. I wouldn't mind accomodating other styles as much if I could set bracing in VS on a per-solution basis, but AFAIK that can't be done.

Anyway … no big deal and no desire to start a Religious War. Just had to throw this one out there ;-)

Bracing Style by Bob GrommesBob Grommes, 05 Mar 2007 18:50
page 1 of 212next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.