Dynamic /methods/ could still be referenced by -> as foo->bar is clearly different than foo->bar().
[email protected] wrote: > I don't object to "->" if that's what it takes to get everyone on > board with properties. I had half hoped that one day java will add in > dymanic methods with the "->" notation (like Fan does), but being > realistic that's not doing to happen. > > > On Feb 8, 11:11 am, Jess Holle <[email protected]> wrote: > >> My thinking is that when you combine Java's lowercase field and property >> naming conventions with use of the existing "." notation for properties >> you cause confusion. Sure you can create rules that eliminate all >> ambiguity, but these are inevitably tricky for developers. For instance >> if foo.bar means the bar property unless this occurs within the class >> itself (or an inner class thereof?), then code may dramatically change >> meanings when moved in/out of the class. >> >> If the "->" notation is used, there's no such ambiguity, but there seems >> to be a great deal of resistance to this as (1) C# uses "." (as does >> Delphi, right?) and (2) it is one more character in the source code. >> >> -- >> Jess Holle >> >> [email protected] wrote: >> >>> If you are a Java coder and you don't use an IDE, you are crazy and >>> are giving up huge productivity gains. But that's another thread. >>> >>> But yes, you should be able to look at a code snippet and tell what's >>> going on. But I don't think properties would be hard to follow. I >>> never had an issue in Delphi or my limited time with C#. >>> >>> On Feb 8, 8:14 am, Jess Holle <[email protected]> wrote: >>> >>>> Hmmmm.... >>>> >>>> I still know a good number of Java programmers who don't use IDEs. I >>>> see ad hoc code review and browsing via e-mail or web pages with >>>> insufficient knowledge of the code to do such highlighting. >>>> >>>> While I use an IDE, I've always been reluctant to assume that somehow >>>> the usage patterns around me will change in response to syntax >>>> necessitating them. I've also kind of assumed that the language could >>>> be developed in such a way that it was sufficiently obvious that you >>>> didn't need an IDE to get the gist of code snippets. >>>> >>>> -- >>>> Jess Holle >>>> >>>> Reinier Zwitserloot wrote: >>>> >>>>> Not convinced myself that this is an acceptable alternative, but: >>>>> >>>>> What if we just bite the bullet and say that use of an IDE (or at >>>>> least a /very/ smart syntax highlighter) is so commonplace that they >>>>> may be assumed? Then the editor could render properties in italics, or >>>>> something. Problem solved? >>>>> >>>>> It's better than m_*, you have to give me that :P >>>>> >>>>> On Feb 7, 3:48 pm, Jess Holle <[email protected]> wrote: >>>>> >>>>>> Jess Holle wrote: >>>>>> >>>>>>> joncfoo wrote: >>>>>>> >>>>>>>> What's wrong with syntactic sugar and how is it holding it back? The >>>>>>>> properties that C# sports are simple, concise, and easy on the eyes. >>>>>>>> Why isn't the Java language picking up at least these basic features? >>>>>>>> >>>>>>> What clearly shows in the Tutorial below is that C# inherits >>>>>>> Microsoft's horrible m_* naming convention from C++. >>>>>>> >>>>>>> What is also 100% clear is that such naming conventioned are >>>>>>> absolutely necessary for clarity due to the way C# does its >>>>>>> properties! The fact that C# uses "object.PropertyName" for access >>>>>>> necessitates that either (1) you use a goofy m_* convention for fields >>>>>>> or (2) you use the capitalized form for the property (Name) and the >>>>>>> uncapitalized form for the field (name). (2) by itself is actually >>>>>>> way too subtle in practice -- thus necessitating the goofy m_* >>>>>>> convention. >>>>>>> >>>>>> To be clear, though I don't like the m_* convention, etc, there's a >>>>>> bigger issue here for Java: >>>>>> >>>>>> The convention all Java programmers have been trained with (and that >>>>>> is in all books and training materials and IDEs) is simple >>>>>> lower-case (leading lowercase and camel case thereafter) names for >>>>>> /both /fields and properties (yes, Java *does* have properties; >>>>>> JavaBeans may need improvement, but they're there). >>>>>> >>>>>> Thus mixing Java's longstanding naming conventions with use of the "." >>>>>> operator for property access is a recipe for confusion. >>>>>> >>>>>>> Instead if Java does properties I hope it can just use "->" instead of >>>>>>> "." -- making it 100% clear that this is a property rather than field >>>>>>> access and leaving no such ambiguities. >>>>>>> >>>>>>> As for C#'s syntax for declaring properties -- I don't see any big >>>>>>> step forward here except in the case of auto-implemented properties. >>>>>>> Sure there's slightly less typing and you don't repeat yourself on >>>>>>> getName() and setName(), but there's no big win in other cases. >>>>>>> >>>>>>> Of course the auto-implemented property example raises other issues in >>>>>>> that once you need to move away from an auto-implemented property to >>>>>>> one backed by a field you have to introduce the field and examine all >>>>>>> usages of the property within your class that really should have been >>>>>>> using the field. At this point once again you're back to m_* >>>>>>> conventions if you want any sort of clarity in the code. >>>>>>> >>>>>>> Overall, I certainly wouldn't say Java should just copy C#'s >>>>>>> properties! This is not rubber-stampable. >>>>>>> >>>>>>> -- >>>>>>> Jess Holle >>>>>>> >>>>>>>> On Feb 6, 1:16 pm, Reinier Zwitserloot <[email protected]> wrote: >>>>>>>> >>>>>>>>> "It is just syntactic sugar" gets you perl. >>>>>>>>> >>>>>>>>> That's what's holding it back. >>>>>>>>> >>>>>>>>> On Feb 6, 7:24 pm, joncfoo <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Regarding properties: >>>>>>>>>> What is holding them back from implementing properties like they are >>>>>>>>>> in C# since it could be implemented as syntactic sugar. >>>>>>>>>> >>>>>>>>>> Plenty of examples >>>>>>>>>> here:http://www.csharp-station.com/Tutorials/Lesson10.aspx >>>>>>>>>> >>>>>>>>>> It would be nice to traverse large object graphs w/o having the ugly >>>>>>>>>> getters. >>>>>>>>>> >>>>>>>>>> E.g. >>>>>>>>>> >>>>>>>>>> // before >>>>>>>>>> obj1.getObject2().getObject3().getObject4().setSomeProperty(1234); >>>>>>>>>> >>>>>>>>>> // after >>>>>>>>>> obj1.object2.object3.object4.someProperty = 1234; >>>>>>>>>> >>>>>>>>>> It is just syntactic sugar... >>>>>>>>>> >>>>>>>>>> Jonathan >>>>>>>>>> >>>>>>>>>> On Feb 5, 9:47 pm, Bill Robertson <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> On Feb 4, 11:58 am, gafter <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Although I believe the syntax is not ideal in its current form, I'm >>>>>>>>>>>> not going to spend more time on it until Sun formally decides they >>>>>>>>>>>> want to move forward with it, and that's not going to happen in >>>>>>>>>>>> JDK7. >>>>>>>>>>>> >>>>>>>>>>> I certainly understand that position, but I think its worth >>>>>>>>>>> considering syntax, even if only in a passive manner (i.e. just >>>>>>>>>>> think >>>>>>>>>>> about it). I've been dealing with C++ recently, and man oh man* I >>>>>>>>>>> forgot what a pain that was after not having touched it in so long. >>>>>>>>>>> Generics nudged Java syntax in this direction, and the little bits >>>>>>>>>>> and >>>>>>>>>>> bobs of closure syntax that I've seen so far (no specific proposal >>>>>>>>>>> mind you), have left me with that same feeling. I hate to try to >>>>>>>>>>> suggest answers when I don't believe I have good ones, but I also >>>>>>>>>>> hate >>>>>>>>>>> to just complain w/o offering suggestions. So I would like to offer >>>>>>>>>>> up the suggestion of considering keywords rather than oddball >>>>>>>>>>> symbols. e.g. lambda v.s. => >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> *Not to be confused with, "OhmanOh Man," a lesser known super hero. >>>>>>>>>>> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
