Split Base into many classes #2765

Closed
federicobond opened this Issue Aug 9, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@federicobond
Contributor

federicobond commented Aug 9, 2014

The Base class has gotten a bit too big over time, so I decided to make a list of all its static methods and an attempt at a possible partition into several classes. This will probably not get done from one day to another, but I wanted to gather feedback before starting to work on such a big change.

What are your thoughts on this?

Base:

  void main(final String[] args)
  void createAndShowGUI(String[] args)
  void setCommandLine()
  void initPlatform()
  void initRequirements()
  String getVersionName()
  int getRevision()
  ModeInfo modeInfoFor(final File sketch)

Messages:

  void showMessage(String title, String message)
  void showWarning(String title, String message)
  void showWarning(String title, String message, Throwable e)
  void showWarningTiered(String title,
  void showError(String title, String message, Throwable e)
  void showBadnessTrace(String title, String message,
  int showYesNoCancelQuestion(Editor editor, String title,
  int showYesNoQuestion(Frame editor, String title,

Platform:

  Platform getPlatform()
  String getPlatformName()
  String getPlatformName()
  String getPlatformName(int which)
  int getNativeBits()
  int getPlatformIndex(String what)
  boolean isMacOS()
  boolean isUsableOracleJava()
  boolean isWindows()
  boolean isLinux()
  File getJavaHome()
  String getJavaPath()

Settings:

  File getSettingsFolder()
  File getBuildFolder()
  File getToolsFolder()
  File getSettingsFile(String filename)
  void readSettings(String filename, String[] lines,
  void locateSketchbookFolder()
  File getSketchbookFolder()
  File getSketchbookLibrariesFolder()
  File getSketchbookToolsFolder()
  File getSketchbookModesFolder()
  File getDefaultSketchbookFolder()
  File promptSketchbookLocation()

FileUtils:

  File createTempFolder(String prefix, String suffix, File directory) throws IOException
  void openURL(String url)
  boolean openFolderAvailable()
  void openFolder(File file)
  String getLibContentsPath(String filename)
  File getContentFile(String name)
  InputStream getLibStream(String filename) throws IOException
  int countLines(String what)
  byte[] loadBytesRaw(File file) throws IOException
  void copyFile(File sourceFile,
  String loadFile(File file) throws IOException
  void saveFile(String str, File file) throws IOException
  void copyDir(File sourceDir,
  void copyDirNative(File sourceDir,
  boolean platformDelete(File file) throws IOException
  void removeDir(File dir)
  void removeDescendants(File dir)
  int calcFolderSize(File folder)
  String[] listFiles(File folder, boolean relative)
  String[] listFiles(File folder, boolean relative, String extension)
  void listFiles(String basePath,
  File[] listJarFiles(File folder)
  String contentsToClassPath(File folder)
  String[] packageListFromClassPath(String path)
  void packageListFromZip(String filename, Hashtable table)
  void packageListFromFolder(File dir, String sofar,
  void unzip(File zipFile, File dest)
  void unzipEntry(ZipInputStream zin, File f) throws IOException

Logger:

  void log(Object from, String message)
  void log(String message)
  void logf(String message, Object... args)
  void log(String message, Throwable e)
@GKFX

This comment has been minimized.

Show comment
Hide comment
@GKFX

GKFX Aug 11, 2014

Contributor

I like the idea. It will reduce merge conflicts, and make it possible to read the file in old browsers (IE on XP can be overloaded by PApplet.java etc.)
Perhaps Logger could stay with Messages or Base though? It doesn't really deserve its own class. Also, FileUtils is a name well associated with Apache. Might PFileUtils be better? (Or are P* names reserved for core?)

Contributor

GKFX commented Aug 11, 2014

I like the idea. It will reduce merge conflicts, and make it possible to read the file in old browsers (IE on XP can be overloaded by PApplet.java etc.)
Perhaps Logger could stay with Messages or Base though? It doesn't really deserve its own class. Also, FileUtils is a name well associated with Apache. Might PFileUtils be better? (Or are P* names reserved for core?)

@federicobond

This comment has been minimized.

Show comment
Hide comment
@federicobond

federicobond Aug 12, 2014

Contributor

I believe we should eventually replace Logger with the standard java.util.logging.Logger for all cases. Also, using FileUtils should not be a problem unless there are plans for including the Apache libraries.

Contributor

federicobond commented Aug 12, 2014

I believe we should eventually replace Logger with the standard java.util.logging.Logger for all cases. Also, using FileUtils should not be a problem unless there are plans for including the Apache libraries.

@GKFX

This comment has been minimized.

Show comment
Hide comment
@GKFX

GKFX Aug 12, 2014

Contributor

I was talking about the fact that FileUtils is a distinctive name, not technical issues. A new developer, seeing the code FileUtils.unzip(a, b), would likely go to the Apache Javadoc. It doesn't really matter much anyway, but there'd be no harm in calling it FileOps.
As for Logger: would it be easier to introduce java.util.logging.Logger now than to introduce processing.app.Logger and then replace it with java.util.logging.Logger?

Contributor

GKFX commented Aug 12, 2014

I was talking about the fact that FileUtils is a distinctive name, not technical issues. A new developer, seeing the code FileUtils.unzip(a, b), would likely go to the Apache Javadoc. It doesn't really matter much anyway, but there'd be no harm in calling it FileOps.
As for Logger: would it be easier to introduce java.util.logging.Logger now than to introduce processing.app.Logger and then replace it with java.util.logging.Logger?

@federicobond

This comment has been minimized.

Show comment
Hide comment
@federicobond

federicobond Aug 12, 2014

Contributor

Oh, I see. I don't code Java regularly, so I may have underestimated the potential confusion.

Contributor

federicobond commented Aug 12, 2014

Oh, I see. I don't code Java regularly, so I may have underestimated the potential confusion.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 17, 2015

Member

Some of this is implemented in 3.0 beta 4. There's enough that's breaking in Modes and Tools (and some Libraries) in 3.0 that it was time to make the switch.

Member

benfry commented Aug 17, 2015

Some of this is implemented in 3.0 beta 4. There's enough that's breaking in Modes and Tools (and some Libraries) in 3.0 that it was time to make the switch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment