having foo->bar mean something -entirely- different from foo->bar() would be extremely bad.
If -> syntax is used for properties, we must accept that -> is 'taken' and can not be coopted for something else (unless that something is so close in spirit to properties that it would be allright). So, the question becomes, for anyone that proposes adding -> for property reference: Is there another acceptable syntax for dynamic member resolution, and if not, is this proposal so much cooler than dynamic member resolution, that its acceptable that they are mutually exclusive? A -great- example of why tossing new syntax at a language 'because there are no downsides' is faulty thinking. There's always a downside. Properties win, by the way, from dynamic member resolution. hands down. But perhaps -> isn't the right syntax. I'd be just as happy with just using the ., but forcing explicit declaration of 'property nature' on the part of the field declaration. writing to/reading from "this.foo" would always run the getter and setter, no exceptions. If you want to skip them and read the raw field, the property, which is really an anonymous inner subclass of the "Property" class, has a (package?) private field, so, you'd go: "this.foo.field" to read it. This would only work from the same class (or perhaps from others, if package private makes more sense). Just throwing it out htere. On Feb 8, 10:53 pm, Jess Holle <je...@ptc.com> wrote: > Dynamic /methods/ could still be referenced by -> as foo->bar is clearly > different than foo->bar(). > > phil.swen...@gmail.com 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 <je...@ptc.com> 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 > > >> phil.swen...@gmail.com 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 <je...@ptc.com> 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 <je...@ptc.com> 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 <reini...@gmail.com> wrote: > > >>>>>>>>> "It is just syntactic sugar" gets you perl. > > >>>>>>>>> That's what's holding it back. > > >>>>>>>>> On Feb 6, 7:24 pm, joncfoo <jonc...@gmail.com> 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 <billrobertso...@gmail.com> > >>>>>>>>>> wrote: > > >>>>>>>>>>> On Feb 4, 11:58 am, gafter <neal.gaf...@gmail.com> 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
