| "Öö Tiib" <ootiib@hot.ee>: Nov 07 12:54PM -0800 On Monday, 7 November 2016 20:29:22 UTC+2, JiiPee wrote: > good suggestion. I ll think about this. Although it makes things a bit > complicated, isnt it? a simple textout functionality needs a complex > stucture behind it... I said that there are no "best" silver bullets for all situations. It is likely clean and simple when you have more than one different outputter outputting same set of classes. It is likely pointless complexity when you need only simple textout for couple classes. Note that code can be edited! If you are unsure then pick simplest that can solve your issue right now and when you later see that it can't actually pull the weight then rearrange it into next solution. |
| Daniel <danielaparker@gmail.com>: Nov 07 01:44PM -0800 On Monday, November 7, 2016 at 1:25:38 PM UTC-5, JiiPee wrote: > > possible. > you propose: string getName(); > ? so getters for those data memember? I think getters are beautiful things :-) (setters not so much.) But let me digress. I used to participate on comp.object, and one of the difficulties I had with the OO people was what exactly did they mean by objects saving themselves and displaying themselves and printing themselves, etc.? To me they seemed infuriatingly vague on the specifics. So I was happy to find an article by Alan Holub in JavaWorld, http://www.javaworld.com/article/2072302/core-java/more-on-getters-and-setters.html, who explained exactly what he meant by these things, with code. So I read Holub's article carefully, hoping to be enlightened, but instead I found myself asking, did anyone else besides Holub think that class EmployeeUI extends JPanel implements Employee.Exporter { private JLabel nameWidget = new JLabel(""); private JLabel idWidget = new JLabel(""); private JLabel salaryWidget = new JLabel(""); public void addName ( String name ) { nameWidget.setText(name); } public void addID ( String id ) { idWidget.setText(id); } public void addSalary( String salary ) { salaryWidget.setText(salary); } public EmployeeUI() { setLayout( new GridLayout(3,2) ); add( new JLabel("Name: ") ); add( nameWidget ); add( new JLabel("Employee ID: ") ); add( idWidget ); add( new JLabel("Salary: ") ); add( salaryWidget ); } } was anything other than a widget class with setters? Holub introduced Exporter and Importer interfaces, which he identified as interfaces for GOF style builder patterns, but the analogy escaped me; to me they looked like plain old data objects with setters and getters, except reborn as add/produce. Anyway, it seems to me that one of the most widely accepted and successful practices over the last couple of decades is to expose the properties of objects, particularly in the Java and C# worlds. Much to the horror I'm sure of the OO people, typical Java and C# objects expose lots of properties. There are different levels of sophistication when it comes to accessing them, whether through reflection or getters, but in principle it's the same. If you have to lay out fields on a GUI, which would you rather work with, somebody's incredibly complicated concoction of "interfaces for GOF style builder patterns", or simple data objects with getters? Best regards, Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Nov 07 12:35PM -0800 On Monday, 7 November 2016 13:21:52 UTC+2, Popping mad wrote: > > Why operator is qualified as 'std::operator<<'? Do you want it to be in > > namespace 'std'? Why that operator is friend of 'tree::Pstates<cost>'? > It is qualified as std because we are operating in the namespace of tree Yes but AFAIK we can't have friend functions from different namespaces. So if you resolve the defect diagnosed you will be likely diagnosed for qualifying friend function with that 'std'. > http://stackoverflow.com/questions/236801/should-operator-be-implemented- > as-a-friend-or-as-a-member-function#237074 That stack overflow question has seemingly no relevance to your issue nor to mine questions. The operator of yours above does not operate on 'tree::Pstates<cost>' (but does on 'std::ostream' and 'tree::state<cost>' whose friend it is not) so *again* why it is friend of 'tree::Pstates<cost>'? > What? C++ does work in a certain way; I attempted to explain to you how. |
| jon@slashslash.info: Nov 06 05:00PM -0800 On Sunday, November 6, 2016 at 1:46:27 AM UTC-7, Alf P. Steinbach wrote: > But it is one heck of an inaccessible document. ;-) > Cheers & hth., > - Alf Interesting. It seems that you could define: std::string operator-(std::string const&, std::string const&); I had assumed that doing so would be forbidden. I guess it wouldn't break any existing code. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment