Dev-Picayune

So I slapped it in gear and started coding on the previously mentioned file update utility that I need to write. Starting small (as I referenced before). I decided to focus first on the lowest level of the program — copying a file. So I now have a command-line utility (with a problem or two) that can copy a file.

So what’s the big deal? Why am I blogging about this? Because I already have observed several things about Java (and Eclipse) that I wanted to point out.

It’s amazing how simple it is (in some ways) to transition to using Eclipse and Java from C# and VS.NET. Creating classes and writing some code is pretty straight forward. However, I was shocked when I discovered several things. First, I was amazed that it wasn’t until the 1.5 (or 5.0 depending on how you look at it) version of Java that it supported Enumerated data types properly. So immediately, I have decided to switch to doing a 1.5 (only) program. This will also allow me to use Java’s new for-each code as well. Second, and more importantly I was shocked to see how Java’s getters and setters were done.

I should point out first, that in general, I find most things (properties/attributes) do not require a getter or setter. As you move into a more UI widget oriented situation that starts to change, but for the most part, 90% of my class properties do nothing more than set or return a value with no interaction based on that. So having all these wrapper methods has always seemed a little excessive.

In C#, the cool thing about the getters and setters syntax is that you keep perfect syntactic compatibility interfacing with the class whether you have true getters and setters or whether you just have publicly available attributes. So you can switch as you need to. However, you do lose entry point compatibility… you have to do a recompile and you can lose some things (especially in the IDE) because of changes.

Python’s property syntax (which for some strange reason I was not familiar with) is actually like the C#.NET stuff. Same name and everything and the cool part is that because of its dynamic nature, you keep compatibility at the interface level. Very slick. I just wish that it had been used a bunch in wxPython.

Based on the other languages available, I find it amazing to hear the Java folks trying to defend their dorking version of getters and setters. As soon as you compare them to anything else they seem to rather silly.

More observations to come I am sure…

Yesterday and today I have started looking into Java again. Seems a majority of the developers (especially outside of the web guys) at my work are Java guys so it’s sort of expected of me to follow suit. I am not convinced but I thought I should give it a fair shot. Personally, I’d rather work in .NET (which I have been doing for the last few years off and on) or Mono (based on .NET) but still, I have to give Java a fair shot.

A possible project I have lined up at work is writing a utility that copies files from the store servers out to the registers (database updates, program updates, etc…). I’ve expanded the scope quite a bit to also handle major patch and version upgrades of the point of sale software. But it was nice thinking OO for a moment and realizing that I could start very small. I took out a piece of paper and scratched out a few ideas about a FileMover class. And here is where the old separate UI from business logic thing kicks you in the head… I knew that I would probably be using some sort of timer event on the window to nicely work within the system. That meant that my main working method for the FileMover class would be something like copyBlock or copyChunk where I move only a section of the data over. The class will have a status attribute and the initialization parameters will be the source and destination file names. But in a truly separated world where UI doesn’t matter, would I programmatically think to not just copy the whole dang file at once? Shoot, I could just have a static library of methods for doing simple stuff like copying a file. But knowing that some of the files could be as large a gigabyte or more, and knowing that I wanted a nicer interaction with the UI and the OS, it forced my hand on the lower level design.

Obviously, I could really muddy the waters by going threaded and that would take care of some of the external complexities. I could still move things in chunks internally but to the outside it would just look like a single method call. Then messages could be exchanged to report on the status of the copy back to the parent thread. But that’s major overkill in this environment and nothing to be gained except complexity and slower total copying.

Anyway… guess it’s time to move past the “hello world” program and start really using this stuff.

Thanks to an increasing amount of spam and not a single valid external trackback, I have decided to eliminate trackbacks. My other option was to significantly enhance the Perl (yuck) trackback system to notify me via email of a new trackback and also to flag all incoming trackbacks as hidden until I approve them (or one of many similarly themed schemes like black and white lists). But in the end, I decided that I didn’t have the time to work on them.

It appears that others like Jeremy Zawodny think trackback is dead anyway. So it just further justifies my removal of the trackback stuff (and saves me the time of trying to add it to the other two sites).

I am thinking it would be cool to enter the Extend Firefox contest. Now I just need an idea. The bummer is that if don’t win a “grand” prize or a best in class prize then you get nothing. But considering that I don’t even have a real good idea for a project, I guess it’s not that big a deal. Now for a good idea and some XUL.