![]() |
|
SageTV Studio Discussion related to the SageTV Studio application produced by SageTV. Questions, issues, problems, suggestions, etc. relating to the Studio software application should be posted here. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
#21
|
||||
|
||||
Quote:
I also agree with Fuzzy that there's a big difference between using operator overloading or other syntactic sugar to obfuscate your meaning or just show off, and using virtual properties to clarify your meaning in the case when you intend a property to behave like a variable and not like a function (even though it may be implemented by getter/setter methods under the hood). And while it's true that modern IDEs can generate the getter/setter boilerplate for you, the fact that it's necessary to insert such automatically generated boilerplate in the source says to me that there's some gap in the language design. Ideally (although very few languages approach this in practice) the source code should contain only the programmer's intentions, with a minimum of boilerplate. So for instance it should be possible to declare a property as (say) a read-only integer with such-and-such range constraints. Then all the getter/setter boilerplate, range checking, exception throwing, etc should be generated by the compiler (not the IDE's editor) and never appear in the source at all, since at that point it's redundant to the original statement of the programmer's intent. I'd argue that virtual properties come closer to this ideal than explicit getter/setter methods; that's why I call it a deficiency in Java that it lacks such a feature and thereby entails more source-level redundancy and boilerplate. Finally, I don't consider this an argument and am not offended by anyone's contrary opinions. In a past life I was a language designer and compiler writer, so this sort of programming-theory discussion is right up my alley.
__________________
-- Greg |
#22
|
||||
|
||||
I don't think your're going to get any argument that java is deficient in some areas.... it's a language... it's going to be deficient. I think the core point, isn't really whether java is deficient in not doing c# style getters/settings, but whether or not, you should adapt yourself to the best practices of using the language. In java, right or wrong, you have beans, properties, methods, etc. If the language was designed to be used that way, then use them, if for no other reason, then it will make your code easier to review and maintain by other peers that are also using the same language.
Just because C# doesn't require you to create getters and setters, isn't a good enough reason NOT to do it Java. Adapt to the language.
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#23
|
|||
|
|||
Quote:
The other 1%? They update the jar and run their unit, regression, functional, and system verification tests and immediately a new IllegalArgumentException is unexpectedly thrown. Quickly they realize that somewhere they were setting numPages to a negative number and make the fix. Their fix is then deployed along side the new upstream jar and everyone's happy. If the original API exposed the properties directly then hid them to address the negative numPages bug then the first thing you have to do is address all the compile errors that the API change will introduce. After you're done cursing out the upstream API provider for their API breaker you then run your test suites and then find the new IllegalArgException and then you have to address that as well. Exposing class properties, in my experience, always leads to more work down the road. Quote:
* There's always exceptions to the rule, but in general, I stand by this statement. ![]() Quote:
Java: Code:
public class HockeyResult { static protected boolean validateTeamName(String name) { return name != null && name.length() > 0; } static protected boolean validateScore(int score) { return score >= 0; } private String awayTeam; private int awayScore; private String homeTeam; private String homeScore; public HockeyResult(String away, int aScore, String home, int hScore) { setAwayTeam(away); setAwayScore(aScore); setHomeTeam(home); setHomeScore(hScore); } public void setAwayTeam(String name) { if(!validateTeamName(name)) throw new IllegalArgumentException("Away name cannot be null nor zero-length!"); awayTeam = name; } public String getAwayTeam() { return awayTeam; } public void setHomeTeam(String name) { if(!validateTeamName(name)) throw new IllegalArgumentException("Home name cannot be null nor zero-length!"); homeTeam = name; } public String getHomeTeam() { return homeTeam; } public void setAwayScore(int score) { if(!validateScore(score)) throw new IllegalArgumentException("Away score cannot be negative!"); awayScore = score; } public int getAwayScore() { return awayScore; } public void setHomeScore(int score) { if(!validateScore(score)) throw new IllegalArugmentException("Home score cannot be negative!"); homeScore = score; } public int getHomeScore() { return homeScore; } } HockeyResult result = new HockeyResult("Canada", 3, "Russia", 2); result.setHomeScore(-1); // Ooops, throws IllegalArgException b/c of broken contract Code:
public class HockeyResult { private String homeTeam(not_null, not_empty); private String awayTeam(not_null, not_empty); private int homeScore(not_negative, less_than 100); private int awayScore(not_negative, less_than 100); public HockeyResult(String away, int aScore, String home, int hScore) { awayTeam = away; awayScore = aScore; homeTeam = home; homeScore = hScore; } } HockeyResult result = new HockeyResult("Canada", 3, "Russia", 2); result.homeScore = -1; // Oops, throws an IllegalArgException because of broken contract I think both class definitions say the same thing and though the real Java code is much longer to say the same thing, I don't think there's anything redundant in the class def'n? Trying to make the real Java class more compact by exposing the properties might shorten the code, but will undoubtedly eventually cause a massive headache at some point down the road.
__________________
Twitter: @ddb_db Server: Intel i5-4570 Quad Core, 16GB RAM, 1 x 128GB OS SSD (Win7 Pro x64 SP1), 1 x 2TB media drive Capture: 2 x Colossus STB Controller: 1 x USB-UIRT Software:Java 1.7.0_71; SageTV 7.1.9 Clients: 1 x HD300, 2 x HD200, 1 x SageClient, 1 x PlaceShifter Plugins: Too many to list now... |
#24
|
||||
|
||||
Quote:
Quote:
Quote:
But I'll grant that preemptively using getters/setters even in that case does no real harm, aside from a small "use tax" (method call syntax v. assignment syntax) at the point of consumption.
__________________
-- Greg |
#25
|
||||
|
||||
Depending on the implementation, there may be a real processing time use tax for the redundant getters and setters. This all depends, of course, on the use, and the underlying system in use.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer) unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers. Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA. Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S Other Clients: Mi Box in Master Bedroom, HD-200 in kids room |
#26
|
|||
|
|||
Quote:
Quote:
Quote:
People can feel free to hush this thread up, but got to admit it's been awhile since I've had an academic debate on such topics so I'm rather intrigued by the other opinions on the subject. ![]()
__________________
Twitter: @ddb_db Server: Intel i5-4570 Quad Core, 16GB RAM, 1 x 128GB OS SSD (Win7 Pro x64 SP1), 1 x 2TB media drive Capture: 2 x Colossus STB Controller: 1 x USB-UIRT Software:Java 1.7.0_71; SageTV 7.1.9 Clients: 1 x HD300, 2 x HD200, 1 x SageClient, 1 x PlaceShifter Plugins: Too many to list now... |
#27
|
||||
|
||||
I think this thread has been very educational. I feel smarter just being in the same (virtual) room with you guys, though I'm sure it will wear off soon.
![]() Aloha, Mike
__________________
"Everything doesn't exist. I'm thirsty." ...later... "No, it's real!!! I'm full." - Nikolaus (4yrs old) |
#28
|
|||
|
|||
Quote:
![]() |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Any experience in Sun online classes? | PLUCKYHD | SageTV Studio | 5 | 03-23-2010 03:20 AM |
Moving objects leaving trails(after images) | xxilikedirtxx | Hardware Support | 1 | 02-20-2006 05:58 PM |
Dynamically loading/unloading STV | MadAxeMan | SageTV Studio | 0 | 01-26-2006 05:05 AM |
Moving objects flashing - interlace issue? | lbeagley79 | Hardware Support | 15 | 10-14-2005 08:34 AM |
Dynamically Select Live TV Capture Device | kkoz | SageTV Software | 0 | 07-14-2005 11:27 AM |