Names for things
-
[0] This ain't a question. [1] Same component, different issue.
-
This is really bugging me. I'm building a component that is basically a message broker. The broker has a set of services, which in turn have agents for different messages that are actually dealt with by plug in process components. I'm happy with the way it sits together, but I am not happy with the names I have: - Broker = top level component. It was called Server, but that doesn't sit with Service - Service = logical grouping of message agents that can talk directly to each other [there is a separate protocol for out of server interfacing] - Agent = handles individual messages including their state - Process = plug-ins to process different messages; this is where all the business logic lives. I just think the names could be better. The whole thing is set up with config, so these names become important; well I think they do. Any suggestions? Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
-
This is really bugging me. I'm building a component that is basically a message broker. The broker has a set of services, which in turn have agents for different messages that are actually dealt with by plug in process components. I'm happy with the way it sits together, but I am not happy with the names I have: - Broker = top level component. It was called Server, but that doesn't sit with Service - Service = logical grouping of message agents that can talk directly to each other [there is a separate protocol for out of server interfacing] - Agent = handles individual messages including their state - Process = plug-ins to process different messages; this is where all the business logic lives. I just think the names could be better. The whole thing is set up with config, so these names become important; well I think they do. Any suggestions? Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
Nagy Vilmos wrote:
Go on then, trivialise the whole thing
Okay... - Broker = Bar - Service = Bartender - Agent = Waiter - Process = Patron
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
This is really bugging me. I'm building a component that is basically a message broker. The broker has a set of services, which in turn have agents for different messages that are actually dealt with by plug in process components. I'm happy with the way it sits together, but I am not happy with the names I have: - Broker = top level component. It was called Server, but that doesn't sit with Service - Service = logical grouping of message agents that can talk directly to each other [there is a separate protocol for out of server interfacing] - Agent = handles individual messages including their state - Process = plug-ins to process different messages; this is where all the business logic lives. I just think the names could be better. The whole thing is set up with config, so these names become important; well I think they do. Any suggestions? Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
Broker => MessageDispatcher Service => MessageManager Agent => MessageHandler Process => MessageTemplate
“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet
-
This is really bugging me. I'm building a component that is basically a message broker. The broker has a set of services, which in turn have agents for different messages that are actually dealt with by plug in process components. I'm happy with the way it sits together, but I am not happy with the names I have: - Broker = top level component. It was called Server, but that doesn't sit with Service - Service = logical grouping of message agents that can talk directly to each other [there is a separate protocol for out of server interfacing] - Agent = handles individual messages including their state - Process = plug-ins to process different messages; this is where all the business logic lives. I just think the names could be better. The whole thing is set up with config, so these names become important; well I think they do. Any suggestions? Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
-
This is really bugging me. I'm building a component that is basically a message broker. The broker has a set of services, which in turn have agents for different messages that are actually dealt with by plug in process components. I'm happy with the way it sits together, but I am not happy with the names I have: - Broker = top level component. It was called Server, but that doesn't sit with Service - Service = logical grouping of message agents that can talk directly to each other [there is a separate protocol for out of server interfacing] - Agent = handles individual messages including their state - Process = plug-ins to process different messages; this is where all the business logic lives. I just think the names could be better. The whole thing is set up with config, so these names become important; well I think they do. Any suggestions? Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
I'm surprised no one came up with this: Broker -> Pimp Service -> Yeah, you keep that as Service Agent -> John Process -> [...] Job Marc
-
You should read The Name of The Wind - By Patrick Rothfuss[^]. The magicians like "Naming" things as they have a talent in the naming of things.
Simon Lee Shugar (Software Developer) www.simonshugar.co.uk "If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
Isn't it a great feeling when you find the true name of your graphics processor and it responds when you summon it? :)
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript. -
This is really bugging me. I'm building a component that is basically a message broker. The broker has a set of services, which in turn have agents for different messages that are actually dealt with by plug in process components. I'm happy with the way it sits together, but I am not happy with the names I have: - Broker = top level component. It was called Server, but that doesn't sit with Service - Service = logical grouping of message agents that can talk directly to each other [there is a separate protocol for out of server interfacing] - Agent = handles individual messages including their state - Process = plug-ins to process different messages; this is where all the business logic lives. I just think the names could be better. The whole thing is set up with config, so these names become important; well I think they do. Any suggestions? Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
Nagy Vilmos wrote:
Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
I'm curious as to know why you chose "Ringo" (Translates to Apple as far as I recall) as a name. Basically, Naming conventions need to be clear and concise. When naming Variables that might be confusing I comment them in. BillWoodruff seems to have the same idea I have with naming my handles.
Quote:
Broker => MessageDispatcher Service => MessageManager Agent => MessageHandler Process => MessageTemplate
As you can see, it's simple and concise and it actually works. Easy to understand variables = easy to understand variables.
-
This is really bugging me. I'm building a component that is basically a message broker. The broker has a set of services, which in turn have agents for different messages that are actually dealt with by plug in process components. I'm happy with the way it sits together, but I am not happy with the names I have: - Broker = top level component. It was called Server, but that doesn't sit with Service - Service = logical grouping of message agents that can talk directly to each other [there is a separate protocol for out of server interfacing] - Agent = handles individual messages including their state - Process = plug-ins to process different messages; this is where all the business logic lives. I just think the names could be better. The whole thing is set up with config, so these names become important; well I think they do. Any suggestions? Go on then, trivialise the whole thing and suggest I just call them John, Paul, George and Ringo.
It bugs all of us. No matter if you chose wisely or flippantly, 4 years down the track, you are always going to say WTF or WTE, when doing your recognisance on your old code.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
It bugs all of us. No matter if you chose wisely or flippantly, 4 years down the track, you are always going to say WTF or WTE, when doing your recognisance on your old code.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
Broker -> Prime Minister Service -> HouseOfLords Agent -> Mayor Process -> CivilServants Tim
Broker -> Kyle Service -> PCD Agent -> Scarden Process -> Adult Rehabilitation Centre :-D
-
Nagy Vilmos wrote:
John, Paul, George and Ringo
Not very exntensible. I used characters from "The Love Boat" once, and eventually had to add parts of the ship.
This space intentionally left blank.
PIEBALDconsult wrote:
I used characters from "The Love Boat"
I used to work with this idiot who named all his routines after Disney characters.
BALR 8,GOOFY
Yeah, S/370 Assembler. Worse yet, the shop I worked at did not believe in comments. "The code tells you what it is doing." Of course it does, but not why. I didn't stay more than a year there, writing code they couldn't understand nor appreciate because it far more advanced than what they were doing. Even though I wrote it with comments. They thought MACROs were only for libraries instead of your applications. One application I did was 70% MACRO generated and that blew their minds. I used variable named register assignments and that messed with their hardwired brains even more.
BALR RTN,PRINT
Sorry of the rant, I believe names for code are too important and agonize over them as well. I'm not criticizing you either, your comment just triggered a bad memory about bad practices.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.