Reply to thread

Message: [QUOTE="KJ, post: 4127625"] Well, that's just the start of it though. You would then also have to change the type of any signals that are using the local array also. In this particular case, one might be able to say that your package that defines the type should also have a function that returns an array of particular elements since that apparently may be a generally useful function to have when using your package. That would avoid having to do some editing in the area that you mentioned, but as I pointed out, you must have signals that want to use the local array so those declarations would be affected as well, you'll still be editing multiple places when you change a data type. However, it's probably not difficult to imagine there could also be much more 'nichy' functions that are useful in only very limited areas. One could say that those 'nichy' functions probably should not be cluttering up the package, but there really isn't a good argument for 'Why not?'. What looks like 'clutter' to one person is 'consolidation' to somebody else. Why not have 'nichy' as well as 'generally useful' functions that work with a type in the same package? In other words all functions that work with that type go in the same package...one stop shopping. Over time that package grows to pick up more 'generally useful' functions as well as 'nichy' functions that might end up finding other niches to fill. If you think it looks 'cluttered', that is most likely a commentary on your editing skills rather than the idea of packaging all functions together. Of course, in the end, there will be functions that really want to work with things of two different types and then the question about which package to put those functions in will rear its head. Probably useful...but... At some point as you start to parameterize your design to make it more self-documenting you create the situation where it becomes difficult to look at the code and answer a simple question like "What type is signal xyz?" because the declaration becomes buried under mounds of 'self-documenting code' that refers to something here that refers to something there... Kevin Jennings [/QUOTE]

Verification